Kaleb Pederson wrote:

> I'm a bit out of my realm as I'm usually strictly backend, but I'm going to
delving into things like this very soon so I've been paying attention to these
topics for a while now.
>
> Still, I'm quite curious exactly what you mean by unit testing the
presentation layer?
>
> Does that imply that you're verifying what the HTML elements, CSS,and Ajax
results are for given calls to the backend? If so, why not test it at the
backend level?

To add a new feature, you should generally add it at the business layer first.
The goal will be that anything a user can do to the View, a unit test can do,
generally the same way, to the business layer.

In the view, don't test the shiny things. Test that your template system has
injected the correct variables. The tests help preserve these behaviors when you
upgrade & refactor, including when you change the shiny things.

> If you're testing mainly what's going on at the front end, it seems like you
could use pure HTML / Javascript to confirm that things act correctly using some
mocked calls to the backend. I guess you could call it a mocked server, but I'm
essentially thinking of a separate facade / interface that doesn't bother with
round-trip calls to a server (even localhost).

JS only works correctly inside a browser. Tests should run under 10 seconds,
from an unattended script. Browsers are not well tuned to be test targets.

Tests on JS should detect that the template systems have injected the correct
data into them. I do this by parsing the JS into a lexical analysis, using
"rkelly", then querying into the resulting parse tree to detect the variables.

> Of course, this doesn't take into account the rendering and cross-browser
compatibility issues, but that's where Selenium Wati(r|n) and friends come into
play.

TDD is not QA testing. At TDD time, we don't need to test that JS commands a
browser correctly, we need to test that our business logic has commanded the JS
correctly. Whether the JS works or not is a different issue.

If the tests constrain JS that does not work, only manual testing will detect a
problem. Programmers should manually test before deploying. If you then upgrade
the JS so it works, the tests should now constrain JS that works. This improves
the odds you don't break the JS when you refactor something.

The systems like Watir that test through the browser are very important, but...

They have provided an entire generation of programmers with an easy entry into
any kind of testing at all. Some projects use no unit tests whatsoever, and they
slowly and painstakingly test everything - including the business logic -
through the View. Some projects have unit tests on the business layers and not
the View.

Of course these tests are better than nothing. Yet in the test food pyramid...

http://c2.com/cgi/wiki?TestFoodPyramid

...a diet of only Watir tests would be like living only on ice cream and beer.
It's fun at first, then the malnutrition begins...

--
Phlip