Page 3 of 3

Re: Testing the output

Posted: Thu Jul 29, 2010 11:01 am
by Jenk
If you want to get elitist about it, you should be writing tests that cover every bit of behaviour before you've written code to satisfy the bit of behaviour you are working on.

I've been amazed by the number of people that claim they have TDD/BDD experience or are even evangelists of them, yet when they actually write some code, they start with the code and not the tests... Test Driven Design is about using your tests to aid design, not just to prove your code works. As josh is explaining, if something is difficult to test, it is likely to be something wrong with the design. If you are actually practicing TDD, you'll already know this because you'll have hit the stumbling block before you have the code even remotely formulated, let alone written and compiled/running.

Anyway, back onto topic of testing the output: Horses for courses. In my experience, it is better to assert snippets instead of absolute layouts in Selenium or other tests applications. Another example being SoapUI test cases for SOAP or other WS-service.

It would seem the true point of this discussion, is that the OP (and anyone else with the same 'problem') needs to actually identify what it is they are testing for, and to also identify if they are trying to test too much at once. For example if you are trying to test that the user gets a (un)successful message after a form submit on an xHTML valid page, you're testing too much at once. Break it down, test that the "successful" message is somewhere in the output, and use (or create) a library to parse and assert the xHTML structure. Perhaps load the output into a DOM parser and navigate through the node tree to the element you want to get the result in? If the page is invalid, the DOM parser will (should) throw an exception.

Rule number one of TDD is to identify your tests. You should never be testing more than one thing at a time, so break it down into unique behaviour.