Adventures with Test Driven Development (TDD)

Source Code – https://github.com/ehelin/Adventures-with-TDD

I firmly believe in testing.  It is the only way to confirm that your software is behaving as expected. However, testing can take many forms.  Almost every software developer will do a happy path manual test.  They have to for confirmation of minimum software onformance to the requirements.  Sometimes this is where they stop and one of the big, big reasons software fails.  The happy path only accounts for perhaps 50-60% of user interactions.  The phrase ‘the devil in in the details’ is very appropriate here.  In normal use, users do unexpected things.  The network may fail.  Or the system may be hacked.  Whatever the case, unexpected functionality can really irritate users, cause data loss or more importantly, possibly expose the system to security issues.

I did a little research on Test Driven Development (TDD) prior to embarking on this adventure, but not a lot as I wanted to see how I approached it just thinking through the process.  According to Wikipedia (see reference #3), ‘Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first an (initially failing) automated test case is written that defines a desired improvement or new function. Then, the minimum amount of code is written to pass that test, and finally one refactors the new code to acceptable standards’.

To implement this, I opted to created an IFile interface, write tests for it that failed and then implement the interface until the tests past.  I chose file input/output because it is fairly easy to test. The implementation does the following:

  • Creates a directory
  • Creates a file
  • Writes to the file
  • Reads from the file
  • Deletes the file
  • Deletes the directory

So, if you go to the Github repository, you can see different commits for each phase.  Specifically:

  • First major commit is an interface, failing tests and an empty implementation.
  • Second major commit is a completed implementation.
  • Third major commit is a set of Nunit tests.
  • Fourth major commit is two additional abstractions so I can use Moq (reference #4) to mock the IFile interface.  Moq is a test mocking framework. I find it pretty easy to use once you get used to it.
  • Fifth major commit was the addition of Autofac to the the object initialization.  Nothing major, but just getting my feet wet 🙂

Stay tuned!
References
1) http://www.infragistics.com/community/blogs/dhananjay_kumar/archive/2015/07/27/getting-started-with-net-unit-testing-using-nunit.aspx

2) http://stackoverflow.com/questions/25304425/visual-studio-2013-doesnt-discover-unit-tests

3) https://en.wikipedia.org/wiki/Test-driven_development

4) https://www.nuget.org/packages/Moq/

5) http://autofac.org/

Advertisements

One thought on “Adventures with Test Driven Development (TDD)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s