Tuesday, January 22, 2013

Test Driven Development

OK, so I've mentioned test driven development (TDD) in several previous articles.  I have to mention here that I have not jumped in with both feet...yet.  My company has a lot of legacy code and I'm waiting for the next project start to jump in.  For those who are starting out like myself, there is a very simple example available here:

Test Driven / First Development by Example

I would recommend reading the whole thing.

For a more complete article on the subject of TDD including testing the business layer and testing the interface layer, I would recommend this article:

Test-Driven Development in .NET

NUnit and DotNetMock are used in this article.  If you have a favorite article, please be sure and leave a message.  I'll update this post with a complete list.

- I'm back!

I'm half-way through the book.  One item I would like to mention in Ninject, dependency injection software (Ninject).  The book covers an example of using Ninject for mocking an object.  The Ninject website wiki ("Visit the Doja", Documentation) doesn't seem to work.  I've tried it under ie and chrome and it just sticks at "loading..."  I have not physically tried Ninject yet.  My first impressions of their website is that it's not very active.  I've also never heard of Ninject before this book, but it might just be new.

OK, on to another subject.  The book goes into a sample project halfway through.  The author breaks down non-functional requirements and details how choices need to be made.  Choices such as: .Net, PHP, J2EE, Ruby on Rails, etc.  Choices on server technologies and on and on.  The author(s) must be assuming that this is the first project that a company is performing and the person reading the book is totally new to developing software for companies.  To be thorough, it's a good idea to cover the basis of this.  However, I would assume that anybody reading this book is already knee-deep in alligators and the reason they are reading about test driven development is because they are familiar with the down-side of fixing a lot of bugs and customer/employee complaints.  So I'm grinning when I read this part, because once a technology is purchased, it's pretty much set in stone.  Don't get me wrong, you could switch from PHP to .Net (or vice-versa) or you can build a second server (or server farm) with PHP right along side your .Net environment, but why would you?  So for the beginning of chapter 6, I'm assuming that most people have this stuff already set in stone.  In other words: Many times the best platform to build software on is the one that is already purchased and in place.  Not necessarily the best to get the job done.

With that said, technically, almost any web application can be built around either Unix or .Net.  Any PC application can be written in C++, C#, Java, etc. and be created to perform the same functionality.  Most decisions are driven by the technology available and at what price.  Assuming you are starting from scratch, keep in mind that any software you build will probably last 3 times longer than you anticipate and you'll be stuck with whatever hardware it runs on.  So if you pigeon-hole yourself into a Unix-based environment right from the start, it'll be very difficult to get out after several thousand hours of development go into your business software.

Back to the book.  So far This is a very enjoyable book to read.  I personally believe it should be on the bookshelf of every company that is building software.  Every developer with a desire to transition into test driven development should read this book.  After I've read through this book, I plan to run through the sample applications in the book and see how this works in more detail.

Stay tuned.

- I'm back again!

The author(s) have started the sample project (half-way through the book).  They describe a directory layout that they use when creating projects and solutions.  I like the use of a libs directory to contain all the dll's and code needed for 3rd party objects.  I slapped my head when I read that due to the fact that my developers and I have had difficulty in assigning a directory to contain all these.  It didn't occur to me to include them into the project and check them into the team server.  The advantage of doing this is that the correct versions of these libraries are always with the project they were used in.  Therefore, future versions of projects with upgraded libraries will not break old projects.

The authors also talk about a library called NBehave.  The purpose of NBehave is to make assert commands easier to read.  I'll be testing this in the near future.  I plan to finish reading the book, then I'm going to go back to the sample application and build it while re-reading the chapters where the project is built.  That way I can see what is going on.  A lot of complexity is going into mocking objects and it gets difficult to follow the sample precisely.  I think I'll start another post when I get to that point.