You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Functional Testing: what to test?

July 5, 2012 — JaZahn

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. #!

Posted in ATG, Yii. Tags: , , , , , . Comments Off on Functional Testing: what to test? »

Agile: doing UI first

July 1, 2012 — JaZahn

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 »

Behavior Driven Development Frameworks

June 10, 2012 — JaZahn

I’ve been going nuts integrating Behat into Yii because BDD seemed so cool. Behat actually provides a yiiextension, but I’m not proficient with phars (think php jar), so it was annoying to get it integrated with Yii.

PHPUnit_story was cool and convenient, but was deprecated in 3.5 and removed in 3.6 in favor of behat.

Upon further reading though, I made the realization that Behat is unnecessary and very much a waste of time. The developer is the only one who will be dealing directly with the unit tests, so by turning the unit tests into awkward-english is just obfuscation. It will make less sense to the person working with the code and adds a layer of work to the project.

I am not saying anything bad about BDD, but BDD doesn’t need a DSL to be BDD. The test methods can still be written for Behaviors and it will still carry with it all the BDD benefits.

RoR*’s Cucumber should also be mentioned. The RoR community seems to have really embraced the BDD framework Cucumber. It should also be noted that RoR community seems to set the trends for other framework niches. That being the case, maybe cucumbers are in everyone’s future.. but as of now, the practice has not caught on anywhere else. Behat is the least popular PHP lib I’ve ever worked with. JBehave is considered out there. Same with Python’s “Lettuce”.

* Opinion: I consider Ruby to be a hobby language. People don’t make real applications in RoR, they’re more academic with it. Which isn’t bad, I’m glad to see Java displaced as the academic language, but people actually do stuff with Java. Ruby is a fine play language, but people who do Ruby, are probably not doing anything real.

Posted in ATG, PHP, Yii. Tags: , , , , , . 2 Comments »
«
»