Primary Menu

Monthly Archives: March 2011

Test-driven development (TDD) is a software development processthat relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finallyrefactors the new code to acceptable standards. Kent Beck, who is credited with having developed or ‘rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.[1]

Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,[2] but more recently has created more general interest in its own right.[3]

Programmers also apply the concept to improving and debugginglegacy code developed with older techniques.

TDD Cycle

Although TDD doesn’t mean you write your tests first, test-first development relies on the process of writing a requirement to add a feature, functionality in the form of short unit-test, watching it fail first, then implementing the classes, methods and properties defined in the test, bit-by-bit, and then watching it pass, which is why it’s also sometimes termed as red-green (fail-then-pass) refactoring. Test-first or not, Test Driven Development makes Tests first class citizens of development process, rather than an after-thought.

Concerns and Benefits

There have been several cases against using TDD or Unit Tests in general, common concerns being,

Oh, this means the developers have to spend extra time writing unit tests, which they could be spending on “actual” development adding “features”.

Well, it’s going to either need more developers to make up for the time lost and increase project costs.

So you are saying we don’t need QA anymore, if Unit Tests are going to take care of all the testing?

and so forth…

Some benefits of Unit Testing in general,

The Project is going to gain a lot more time actually spent on quality, although more time might be required upfront to ensure unit tests are written for as many cases possible. However, the confidence in the quality of the code will be high for each developer. They will be able to know a defect they fixed is not going to break something else, very quickly. Immediate feedback, less QA cycles.

Cost associated with adding more developers is going to pay back once you have lesser QA cycles, immediate feedback on buggy code, lower long term maintenance and QA costs. It’s important not to conclude based just on the initial increase in development time and cost.

Generally it’s not a good idea to add more developers just to write unit tests for code that’s being written by some other developer. Ideally each developer who implements a feature or functionality has to write his/her own unit tests, and then be peer reviewed for accuracy and design

Unit tested and TDD code is likely to create and force automatic optimum design, also it’s going to help discover bugs in existing/legacy code – this is why it’s also sometimes called Design Driven Development. The API is going to evolve and emerge just enough to end up being optimum, on-demand design and avoid any upfront, grand ivory tower design that usually is a pattern in the Waterfall methodology.

Unit tested code is more likely to create a sense of ‘care for the code’ from a developer’s standpoint, and not writing code ‘just to make things work’

There could be more many more that I missed, please feel free to add.

Now, these benefits depend on how TDD is adopted and practiced and the results may vary on case by case basis. Also there are situations when writing unit tests for every part of the application is not feasible or possible. For example, UI testing, which is a whole another topic. For UI testing it is recommended to have Automated Coded UI tests, validating parts of the application that can not possibly be tested using Unit Tests.

Types of Testing

Generally there are 3 types of Testing areas. It’s important to know their differences and purpose.

Unit Tests – focus on testing classes, methods and API in general, interacting with APIs of the various modules of the application. Goal is test functionality at a micro level and make sure each unit of code is accurately functioning as expected.

Integration Tests – focus on testing multiple coherent components/modules of the application. Goal is to validate if they work together as expected. This might include Presentation layer interacting with Business logic / Middleware and databases.

Automated/Coded UI Tests – focus on UI and how the user interacts with the application – test cases generally not covered by the Unit Tests or Integration Tests.

All the above 3 types of tests are known to significantly reduce cost, maintainance and resources for the Project.

Research and Case Study

To that point, a research was conducted by folks at Microsoft which weigh in costs development time vs benefits.

Quoting from that research whitepaper,

Test driven development has recently re-emerged as a critical enabling practice of agile software development methodologies. However, little empirical evidence supports or refutes the utility of this practice in an industrial context. Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

Javascript: The Good Parts, is the name of the one of the greatest book written on modern Javascript. Author Douglas Crockford who invented his own JSON spec and also invented JSLint explains why Javascript is not an inadequate language of the web after all. It’s good parts make up for anything that’s wrong or inconsistent. You just have to learn to know it.

My first stint with Javascript was when I started my career in web development back in 1999, writing HTML, CSS and Javascript with Classic ASP on the server side. We worked through hoops to make things work on Netscape and IE (we had to worry about only two browsers back then, but more later on), then there were elaborate, error-prone hacky javascript files (document.getElementById all over the place) we included in pages to take care of client side validation, UI manipulation and XHR. Yes, all the good things of the web today were available to be used back then in the 1990s, especially with the MSIE browser. We just had to know to use it. AJAX was already there.

Since the arrival of modern javascript libraries like jQuery, made the life of a Javascript programmer so much easier. Letting you focus on “What to accomplish” more than “How to accomplish and bring it all together”. Which is great. It also provided a better separation of concerns, getting rid of inline event handling hooks and styling. The MV-VM Javascript library KnockoutJS is yet another tool in the kit, that has brought goodies like observable properties and arrays, viewmodels etc to the web programming arena. With appropriate use of jQuery Templates, you can get Silverlight/WPF like data-template and control-template like capabilities. This morning I discovered d3, this helps dealing with both DOM and SVG way easier.

I am excited how things are getting more and more standardized and easier to use with all the excitement around HTML5, CSS3 etc.

Now on to Tools. One of the areas where ‘Web Development’ lags behind compared to Desktop/Client development is Tools. Tools that are transparent, easy to use, provide context, help and do not stand between the developer and the end result. Historically all these deficiencies have scared away the transition of a VB developer in to the pure web programmer, and thus ASP.Net came in to prominence making the developers not think about javascript, html at all and live in the land of Server Controls, View States and Magical unicorns, in the name of productivity, RAD or whatever you want to call it. While I completely agree ASP.Net filled a void and served well it’s real purpose at the time, it also delayed the emergence of frameworks like ASP.Net MVC. I am speaking in the context of a Enterprise .Net developer here.

ASP.Net MVC brought the shine back to web development on the MS .Net stack. When you have complete control over your markup, scripting, styling, URLs, routing, views, controllers and models, you can have greater transparency and focus on “What you want to create”. Yet built on top of the same ASP.Net’s core foundation, which is solid and evolving with each new version.

Coming back to Tools, I am crazy about ‘Chrome Developer Tools’. It’s brilliant. Simply love the way Chrome is supporting developers by providing context based, transparent and easy to use information about what got rendered on the client and moving away from just relying on “view source”. All though IE-9 is trying to catch up, when you compare, Chrome is years ahead of IE-9.

You might also want to use pure web-based tools like the awesome JSFiddle. For a full introduction and how-to guide for JSFiddle.Net, read this blog post by Ryan. I am using it on regular basis, when there is a need to create any client side UI development. Prototype it there, once it’s functional, bring the source code back to your application.

To sum it up, you always get good support from Visual Studio debugger and the VS tools to troubleshoot and inspect server side code, and VS does a splendid job of it. In VS2010, the Javascript intellisense and debugging support is great. However without an accompanying browser based Developer toolset your client side development is open to lost productivity, too many trial and error fixing sessions and frustration. This frustration eventually leads to a statement like “Ohh I hate javascript, html and this web development, Windows Forms/WPF/Silverlight development is so much better”. The important thing to note here is that it’s not the web development model that is difficult to deal with, it’s the tools, and the stateless nature of the web. So, you do need things like ‘Chrome Developer Tools’ to fill the gaps and make things happen quickly and efficiently. It’s not perfect, yet, but it will get there, if you use it, you’ll know what I mean.

I wish Visual Studio can provide all three in one place. The Browser Developer Tools, a playground to prototype client side features like JSFiddle and then great, easy to use, built-in Javascript debugging.

After I recently started using KnockoutJS, the awesome MV-VM Javascript library, I came across several samples which serve as a great reference for real-world scenarios to solve specific UI problems. Because it’s hard to get to when I wanted to take quick look at, thought of making a list. This is an evolving list, so will keep adding samples as I find them.

I am sure you will find them useful.

The reference samples are created by community and are mostly on the JSFiddle.net