Functional Testing: what to test?

I’ve been working with PHPUnit’s SeleniumTestCase. I worked out some good login switching for the two authentication schemes I’m working with. Then came time to actually write some tests. But what to test?

Unit testing tests a single class. A singular piece of code or a unit. I typically write unit tests for Models only. Integration testing tests the interaction of multiple units or units with multiple resources. I’ve been thinking of these as sort of testing the Controller. That’s a little simplified, but it’s not really something I have a framework for with Yii and PHPUnit. Functional testing likewise has varying definitions. Some people like to focus on the testing of “functional requirements of the product” and some people have a more simplistic view of it, that it’s just automating tests of the views — so it can be used as integration testing. I personally think the former is a better way to look at it, but it also sounds a little douchey to say it out loud.

So I’m totally agile. I’ve got all these user stories. And all these tasks. What I’m doing is writing the functional tests in terms of the user stories and tasks. This is sort of BDD, except I’m ignoring the excessive mocking, which basically makes the BDD tests unit tests, and doing the whole shebang at once. Shebang isn’t being picked up by spellcheck. #!

Agile: doing UI first

I was going nuts about BDD recently. One of the most exciting things about it was the idea of doing all of the UI first. The idea is to deliver something to the client before too much of the back end is developed, so they can say if you’re on the right track — apparently this is a major agile tenet.

I’ve thought this way for a long time. For my current job’s interview, when asked how to start a project I replied to do all the UI first. I don’t think that’s what any job actually wanted to hear, I know I’d given that answer 100 times before, and I know no one ever liked it. I got lucky that the group I interviewed with was in such disarray they didn’t realize it probably wasn’t the answer they were supposed to be looking for. But that was years ago, so maybe that answer makes more sense in these agile driven days.

Oddly, this wasn’t covered in the 3 day agile training I recently finished. Maybe it’s covered in the recommended 5 day version.

My issue has been trying to write user stories that only cover the UI without basically duplicating all user stories and adding “UI” to them. I originally went with one user story that just had (basically) “do all UI”. Artie rightly pointed out that is an epic, and needs to be broken down for user stories.

The best I got was to break it down by themes. Take Quizmo as a simple example.

  • All Quiz Management UI
  • All Question Management UI
  • All Quiz Taking UI
  • All User Management UI
  • All Student Viewable Reporting
  • All Admin viewable Reporting

I don’t actually think this is right, because this relies on implicitly knowing all user stories from the get-go. Perhaps the right way would be to have 2 sets of story points for each story, one for the UI and one for the complete execution. This would mean running the same story card twice.

I’m sticking with the “UI by theme” approach for now.

Posted in ATG, Quizmo. Tags: , , . 2 Comments »