Pekka Laukkanen wrote:

> 1) How do you automate testing browser compatibility through the
> business layer? Or do you plan to do that manually for all the
> browsers on all operating systems?

Then you are testing the GUI directly - the test case is close to the tested
case.

Then, if such a test fails (conceptually or literally), you fix it by changing
code in your real unit tests. For example, suppose your HTML accidentally
duplicates IDs - which is forbidden - and automated (or manual) testing
discovers your Javascript does not get the right object thru its ID on some
browsers.

You naturally improve the GUI tests in that area. But the bug is not fixed until
you have improved the unit tests. By "unit" I mean tests that...

- mock the server, so no HTTP or browser get in the way
- interpret the HTML that would have gone out the wire
- parse the HTML with queries, such as XPath
- assert the HTML does not contain various tell-tale signatures

That way, you improve the confidence that a developer's instant unit test
successfully defends behavior real browsers depend on - even if test finds that
actual behavior inconceivable.

So an HTML test could validate entire pages, such as with Tidy, to fail if any
IDs get duplicated. Then an XPath test could find the specific IDs that matter -
no matter where they moved on a page - and could verify their internal details.

> 2) How do you automate full end-to-end tests if you only talk to
> business layer? End users don't really care if the business logic
> works flawlessly if the UI to it doesn't work.

Sometimes a GUI test covers business logic. I took care not to say they never
should. But, once again, there had better be a unit-level test that covers the
exact same business cycle.

> For me the ideal situation is where requirements can be expressed in
> natural language, and executed as acceptance tests against different
> interfaces by changing the driver that is used. This way same
> requirements/tests can be executed both against the business layer
> (fast, might be ready before the UI) and the actual user interface
> (real end-to-end test). In web-testing world this can even be extended
> so that same tests can be executed using a browser driver (e.g.
> Selenium RC, Watir) or a driver working on HTTP/HTML level (e.g.
> HTMLUnit).

Awesome idea - I didn't even think of it like that.

I suspect that some people abuse GUI tests to cover internal business logic.
That's an antipattern...

--
Phlip