Test classification...

[nielsene]

I'm not sure if I'm confusing myself on unit versus acceptance testing.

Currently my test directory structure looks like:

Code: Select all

tests/All.php
tests/acceptance-tests/All.php
                                /<moduleName>/All.php
                                                        /<long multi-page process test>
      /unit-tests/All.php
                     /classes/All.php
                                /<class hierarchy>/All.php
                                                           /<assorted tests cases>
                     /web/All.php
                             /<moduleName/All.php
                                                   /<ModuleFunctionality>/All.php
                                                                                    /<little test cases>
      /include/test_setup.inc
                 /<Custom Subclasses of Unit/Web TestCases>
                 /sql/<preload scripts>
     /var   (holding space for temp files, etc)

As you notice web stuff gets tested directly in both the unit and acceptance trees. My code is still a mix of procedural/OOP. Most of the serveable pages somewhat like a PageController with TemplateView, combined. Some are self-submitting and some have better logic/display seperation.

In either case I "needed" the unit-test webtests to drive the development of the user visible web-page and processing -- ie assertField in order to have a test for a field on a form, before adding the field, etc.

The acceptance tests on the other hand are long tests of a multipage form process.

I can see how as more and more of the code fets refactored, I'll have less need for the web unit tests as they'll move into classes and thus into the class subtree.

In the meantime, is this a logical distinction between unit/acceptance tests for the web side of the house?

[McGruff]

All web tests are acceptance tests, I think. They're testing end-to-end by exercising UI commands and relate directly to client requirements.

[nielsene]

All web tests are acceptance tests, I think. They're testing end-to-end by exercising UI commands and relate directly to client requirements.

Then how do you drive the developmnet of views? (Especially of the Template View variety)

[McGruff]

Fowler mentions using helper objects with TemplateView. The template itself is as thin and dumb as you can possibly make it and so a unit test for the helper can go a long way towards testing the view.

The helper would gather all the data, and maybe do some presentation logic. I suppose it could also be more passive, ie passed around to other objects which add data to it rather than asking them for the data.

But there's still that damned UI to test...

You could mock/stub a helper object to set up some sample data then include a template file and buffer, making assertions against the contents. I really must look at the web tester code (which can for example look for visible text, ignoring tags) and see how that can be used to examine a buffered string.

The acceptance tests perhaps do not need to test page content with the same fine-grain. Here, you're testing navigation and application logic such as logging in with a valid name & pass gets you into the admin area whereas an invalid one doesn't. With this approach, you don't necessarily need to assert every last dot and comma - just enough to prove that it is the page you think it should be. I'm still feeling my way really.

To cries of horror, you can also test the template output with the best tool for the job: the human eye. Automated testing can only go so far. You can check if an iterator loops its loops by asserting content in a buffered string, or if a conditional happy birthday message is being correctly displayed but you can't tell if the CSS breaks in IE, or if a tree-frog green background is clashing with a salmon pink header. Really at this point I feel like I've left the app behind.

[nielsene]

So you wouldn't have a Unit Test like

Code: Select all

class FooFormDisplayTest extends WebTestCase {
   function FooFormDisplayTesst() {
      $this->WebTestCase("Test Display of Foo Form");
   }
   function setUp() {
      $this->get('someWebPage');
   }
   function testFormElements() {
      $this->assertField('firstName');
      $this->assertField('lastName');
      $this->assertField('submit');
   }
}

As the driver for the form generating code/template?

Of course if your design has a "form" class you can simply test if its "display" method generates the right string.

[McGruff]

No - although that might be part of an acceptance test, later on.

One of these days I'm going to have a look at doing the same thing with buffered template output rather than an http response. That would allow you to use TDD to help create template files. Of course you don't need the Simpletest parsing to assert buffer contents, but it's got lots of nice assertions ready made like assertTitle etc. In particular, some assertions such assertWantedText ignores tagged text which is very useful.

[nielsene]

I'm still a little confused here.

In the Astel TDD book, he runs through an example of creating a GUI-based application using TDD. He has unit tests to drive the inclusion of dialog controls, etc, into the screen. This seems identical to using a unit test to drive the inclusion of a form element into a view.

Yes if you're using Two Stage View and/or Transform View, you can probably test for it at a class level. But if you're taking a Template View approach or even a combined Transaction script for a simpler site, it seems you'd have to unit test the form via a web-test case. Its not an acceptance test -- its written before the code, to drive the inclusion of new feature. Its not testing if the button does anything, etc, Only that the button/element/whatever is there.

I understand that output is past a cartesian boundry of the application, but its still development code that should be tested and build using TDD.