Real Simple Test Driven Development in Visual Studio

 

Step 1

Decide the feature you need to implement. In this case I have decided that my DefaultNewsProvider class needs a method for returning a single news item when passed its Id.

 

Step 2

Open your test file that is responsible for testing the DefaultNewsProvider class (in this case it is in my Keima.Website.Data.Test/NewsProviderTests).


Step 3

Write the test with the expected result. I know that in my database their exists a news item with an Id of "tag:keima.co.uk,2008-06-26:Composer 2.0 Launch", therefore I construct a a test that calls the new GetNewsItem method with the Id, then compares the result to check we have been given the correct item back.

 

Step 4

We have hit a problem, this method does not actually exist despite having the test for it. So, bring up the code helper and generate the method stub.

Step 5

Test the code. Go on. Watch it fail.

 

Step 6

Make it pass. In this case its easy, a sort of 'fill in the blanks'. So back to DefaultNewsProvider it is and the implementation is finished off.

 

Step 7

Re-run the test, watch it pass. All is well, the code has been added, a test has been created, and if in the future the method breaks due to other code changes you will know immediatly.

 

List of reasons why test driven development can help you:

 

+ Allows your code to be maintainable, shows the exact point of failure of a program, none of this nasty debugger related stack tracing and breakpointing anymore
+ Forces you to focus upon the expected usage of a function, not the specifics of its implementation. Once you get in to the TDD mindset this allows you to be more concerned with the abstract ideas of how the project should be designed and structured with maintainability in mind as opposed to language specific implementation details (e.g. "I need a function that returns a file handle given a file name or null on an invalid file" rather than "What calls need to be made inside C# to open a file?"
+ At any one time, your code WORKS. Ensuring that code is correctly covered by tests allows you to guarantee that at any one time your project can be built and shipped to a customer. 
Your tests are more accurate (bold assumption I know, but here me out). Designing the code by considering how it will be used, and ensuring that tests are constructed at the beginning is much more preferable to designing tests once a project is finished, where code may be missed, meanings of code blocks forgotten about or motivation does not allow for proper testing.

 

A few other notes
+ Name your tests properly. GetNewsItemReturnsCorrectItem is much more imormative than GetNewsItem, especially in large applications where there can be tens of thousands of tests, it just makes finding the cause easier.
+ You _will_ be writting more code.
+ For each function, class and library you have have a matching Test function, class and library.
+ Try and have three tests for each function, a test that returns the correct result (like show above), a test which tries to break it (an invalid id) and a test which is just plain wrong (passing null in for example).

 

As ever address any personal experiences, observations, suggestions or death threats through the comments.

Post Metainfo

Real Simple Test Driven Development in Visual Studio was published on Sunday, July 6th, 2008 at 2:13 am and is filed under Keima, Programming, Uncategorized, Work. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

« Your Top 10 Albums | T -1 »

2 people commented on “Real Simple Test Driven Development in Visual Studio”

  1. Paul @ July 24th, 2008  

    Thanks! Very informative. How do you organize your file/logical structure in Visual Studio with the actual code and all the additional pieces of test code?


  2. admin @ July 24th, 2008  

    Hi Paul,

    It depends upon how you structure your code base. Basically what I do is mirror all my projects/namespaces/functions so each one has a test project associated with it (even if it is empty for the time being). To organize my files I mirror the namespaces within the solution, consider the namespace (with company being the namespace root):

    company.library.project

    would be the physical path:

    Solution\Library\Project.csproj

    To manage my tests I would then have a folder in the root level of the solution called ‘Tests’ which would mirror the tests for each library, however I would name my test library for project

    company.library.project.tests

    which would have the physical path:

    Solution\Tests\Library\Project.csproj

    This is of course entirely up to you, you may wish to place your test projects side by side with your projects.

    Hope that helps.


Leave a reply