PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Mon Dec 17, 2018 10:55 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: Test classification...
PostPosted: Sat Aug 06, 2005 3:35 pm 
Offline
DevNet Resident
User avatar

Joined: Fri Aug 16, 2002 8:57 am
Posts: 1834
Location: Watertown, MA
I'm not sure if I'm confusing myself on unit versus acceptance testing.

Currently my test directory structure looks like:
Syntax: [ Download ] [ Hide ]
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?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 06, 2005 10:05 pm 
Offline
DevNet Master

Joined: Thu Jan 30, 2003 9:26 pm
Posts: 2893
Location: Glasgow, Scotland
All web tests are acceptance tests, I think. They're testing end-to-end by exercising UI commands and relate directly to client requirements.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 06, 2005 10:06 pm 
Offline
DevNet Resident
User avatar

Joined: Fri Aug 16, 2002 8:57 am
Posts: 1834
Location: Watertown, MA
McGruff wrote:
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)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 06, 2005 10:57 pm 
Offline
DevNet Master

Joined: Thu Jan 30, 2003 9:26 pm
Posts: 2893
Location: Glasgow, Scotland
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 07, 2005 10:16 am 
Offline
DevNet Resident
User avatar

Joined: Fri Aug 16, 2002 8:57 am
Posts: 1834
Location: Watertown, MA
So you wouldn't have a Unit Test like
Syntax: [ Download ] [ Hide ]
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Aug 07, 2005 3:06 pm 
Offline
DevNet Master

Joined: Thu Jan 30, 2003 9:26 pm
Posts: 2893
Location: Glasgow, Scotland
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 10, 2005 11:18 pm 
Offline
DevNet Resident
User avatar

Joined: Fri Aug 16, 2002 8:57 am
Posts: 1834
Location: Watertown, MA
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group