Testing the Units

Mind Gravy » Blog Archive » links for 2008-04-02

Mind Gravy » Blog Archive » links for 2008-04-02 — Wed, 02 Apr 2008 12:36:02 GMT

Pingback from Mind Gravy » Blog Archive » links for 2008-04-02

re: Testing the Units

tobsen — Fri, 15 Feb 2008 22:17:55 GMT

@andrew: sure, test the granular parts as well. But your user story can be tested also, without the other parts. I like to use mock objects to really test the flow of a class (e.g. the presenter) and to seperate the it from the implementation of other classes. SO it doesn't matter if SaveRegistrationData is really saving thinmgs as long as the presenter calls it. That imho is "testing the behaviour". Imo the wiki article is no quite right. I consider "calculating the correct value" a functionality (Unittest) - not a behaviour...

re: Testing the Units

PeterRitchie — Fri, 15 Feb 2008 14:44:02 GMT

@sanj: I agree. I hope I didn't come across as being anti-TDD or anti-BDD. My intention was to try to point out that using one of (TDD, BDD, Unit Testing) should not preclude all the others. I believe that they all should be part of your dev testing repertoire. Thinking TDD is all you need to do is not a good thing. Doing just TDD is better than no dev testing...

Do BDD and TDD then follow up and unit test what you now know is needed/used. I don't think user stores should be concerned with implementation-specific cases; but things like boundary cases should be included in dev testing.

You start to dilute TDD and BDD if you couple implementation details into it; decouple that into a separate unit testing effort.

re: Testing the Units

andrew myhre — Fri, 15 Feb 2008 10:33:53 GMT

I agree, I feel more comfortable testing individual class methods and then building behaviour tests which could link several classes into a process.

e.g: Given the user story 'User must activate their account before they can login', I would need to write a test which includes my membership class, email class, database class etc in order to test the entire process. I would write those tests after I've tested the granular parts (e.g: Save Registration Data).

re: Testing the Units

Troy DeMonbreun — Thu, 14 Feb 2008 22:44:24 GMT

My take:

<a href="blog.troyd.net/Test+Supported+Development+TSD+Is+NOT+Test+Driven+Development+TDD.aspx">Test Supported Development (TSD) is NOT Test Driven Development (TDD)</a>

re: Testing the Units

sanj — Thu, 14 Feb 2008 22:41:00 GMT

Hi Peter,

TDD/BDD is part of the agile tool set. In order to be "agile" you only drive out code that you "need" as opposed to writing abstractions that model every conceivable detail. You only extend the abstraction when your stories dictate it, thereby helping you focus on functionality that is currently necessary and not "perceived" in the "future". From experience this is a good thing. By only creating what you currently need you prevent yourself from over engineering solutions and creating code that will most probably be scrapped when the customer changes his mind. It keeps you agile.

You may use interaction or state-based testing depending on the situation. You are not tied to interaction-based testing.

Granted that vanilla unit tests don't tests all scenarios. One reason for this is that unit tests need to execute in a very short time. If we ran test for all the scenarios, say the 4,294,967,296 possibilities in the EratosthenesPrimesCalculator - then our unit tests may never finish running by the end of the day. The longer it takes for something to run the less liked we are to run them. I do agree that unless we test all 4,294,967,296 possibilities that we are not sure that the code works. So we might use a tool like ScalaCheck (code.google.com/.../scalacheck)(if it existed in Java) to test all these possibilities. These could be run as integration test, as we don't run integration tests repeatedly in the TDD/BDD cycle of write a failing test, get it to pass and refactor. So essentially the "unit" tests need to be fast and lightweight and should test boundary cases and some probable inputs and expected outputs. Integration tests or acceptances tests could test all possibilities.

Although user stories don't cover "implementation details like the limits of the "int" type (or "Integer" type in Java) isn't a concern of the users" we as developers should. We know the development platform and it is our duty to verify any assumptions made by the customer on the story cards. In an agile environment you should have access to a "customer" so any of these constraints should be made known to the customer so any changes can be made. (Maybe 4,294,967,296 is unnecessary or too little for the scenario)

TDD/BDD are design tools as people have generally commented. But I do think we have a testing/speccing mindset while using these frameworks and therefore boundary cases and the like have to be tested/specced because it leads to a better design. (eg. What happens when a null is passed into a method? A good design would handle this although it is not on the story card)

Unit Testing the Units

DotNetKicks.com — Thu, 14 Feb 2008 22:35:30 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: Testing the Units

PeterRitchie — Thu, 14 Feb 2008 20:57:04 GMT

Using a test-first approach, you first write a test for a method before you write the method. You only know conceptually how that method is going to be used in a user story (e.g. from TDD By Example, testMultiplication, which tests only that a particular multiplication with one value succeeded). Yes, your specific scenarios could be boundary cases; but one: that's not usually what user stories describe, you're usually testing interactions; two: implementation details like the limits of the "int" type (or "Integer" type in Java) isn't a concern of the users; and three: it couples implementation details to the user stories (requirements artifacts).

re: Testing the Units

edovale — Thu, 14 Feb 2008 20:00:36 GMT

I fail to see how not testing for boundary cases is in any way related to TDD or BDD.