DevOps Zone is brought to you in partnership with:

Dave Bush is a .NET programmer and Certified ScrumMaster who is passionate about managing risk as it relates to developing software. When he is not writing or speaking about topics related to Application Lifecycle Risk Management (ALRM), he is an example to his peers as he develops web sites in the ASP.NET environment using industry best practices. Specific topics Dave can address include: • Project management, with an emphasis on Scrum • Test Driven Development (TDD) • Behavioral Driven Development (BDD) • Unit testing and Integration testing using NUnit, Jasmine and SpecFlow • Web Application testing using Selenium • Continuous Integration • Extreme programming (XP) • Coding best practices • Architecture • Code Reviews Dave has "an insatiable curiosity and is always learning." He has been called "the miracle worker" and "hard to replace" by clients he has worked for recently. Contact Dave via LinkedIn (http://www.linkedin.com/in/davembush/) to find out more about how he can help your organization reduce software development risk Dave is a DZone MVB and is not an employee of DZone and has posted 53 posts at DZone. You can read more from them at their website. View Full User Profile

Test-Driven Development Saves Time — A Story

06.10.2014
| 6049 views |
  • submit to reddit


TDDSavesTime_AStoryI recently had an experience writing code that proved to me, once again, that using Test Driven Development really is faster than the way I have been working.

You will remember a couple of weeks ago I presented a strategy for creating test scenarios where we need to test storing data to a database from a web page.  Well, recently, I had a chance to use that strategy.

In that article, I talked about first testing that the data that we were sending back to the server was actually coming back correctly to the web site.  By doing this, you don’t have to track down where the problem is.  Is it in the database save routine or did it not even get from the client to the server?  This part worked pretty much as expected and my code for that worked right away so I can’t say that I saved a whole lot of time.

But the part that did save me a TON of time is the second half.  Saving the data to the database without having to use the web site to create the data I wanted to save.

While I was testing the client side, I saved the data to a JSON string which I used to create an object that represented the data that had been sent back.  Then in my unit test, I recreated the object from the stream and sent that into my save routine.  Once the save was done, I reloaded the object from the database.  Now I have the original object and the saved object which I can compare.

And the comparison showed me that the save wasn’t quite working the way I had expected.  I actually had to go through several (10? 15? 20?) iterations of fixing and testing before I got to a point where my test was succeeding.  It took about a day to get everything working.  Imagine if I were using a manual method to test this.  Launch the web site, fill out the form (it’s a pretty long form with a lot of data) save the form, reload the form, remember what I had  filled out, verify that everything got saved.  I easily saved half a day using Test Driven Development.

If you are  still on the fence as to the value of implementing test prior to writing code, I would encourage you to try it.  Just try it for 30 days.  Yes, it will be hard getting started.  Yes, it will FEEL like it takes more time to write the test first.  But as you make this part of how you develop code, you will start to see for yourself how many benefits you can realize by implementing this best practice.

Published at DZone with permission of Dave Bush, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Johan Sjöberg replied on Tue, 2014/06/10 - 9:48am

This is where I see most people go wrong - they confuse TDD with testing and treat non-TDD and testing as mutually exclusive. Automated testing helps solve the problem you describe. TDD has nothing to do with it. 

Dave Bush replied on Tue, 2014/06/10 - 6:18pm in response to: Johan Sjöberg

Sorry, Johan, I'm not following.

First you say that "they confuse TDD with testing and treat non-TDD and testing as mutually exclusive" and then you seem to treat TDD as somehow mutually exclusive to automated testing.

I'm not sure what you are trying to say.

Mark Unknown replied on Wed, 2014/06/11 - 8:51am

I think what saved time was separating the "layers".  You can do this without TDD.  It is more akin to DDD. I have done this without TDD since my VB classic days for the very same reasons. That being said , if you don't do this TDD will be harder and of less value.

Dave Glasser replied on Wed, 2014/06/11 - 11:55am

 moved.

Dave Glasser replied on Wed, 2014/06/11 - 11:56am in response to: Dave Bush

I'm not sure what you are trying to say.

I think he was pointing out that you didn't have to write the test first, before the code that was to be tested (which is the TDD way) in order to use automated testing to find and fix bugs. You could achieve the same end without TDD. It was automated testing that saved you time, not TDD.

Mark Unknown replied on Wed, 2014/06/11 - 1:56pm in response to: Dave Glasser

If the reply was to me ... You solved the problem by not having your UI code jammed together with the business logic and database code and etc.  The code was modular. That is not TDD. Modularity enables good TDD.

Johan Sjöberg replied on Wed, 2014/06/11 - 5:30pm in response to: Dave Glasser

Exactly. I prefer the TDD posts to concern the TDD specifics of testing. 

Dave Bush replied on Wed, 2014/06/11 - 7:14pm in response to: Mark Unknown

I think he was pointing out that you didn't have to write the test first, before the code that was to be tested (which is the TDD way) in order to use automated testing to find and fix bugs. You could achieve the same end without TDD. It was automated testing that saved you time, not TDD.

Yes, I might have ended up here without using TDD.  I could implement many good designs without using TDD.  But having to write tests influences design and, specifically, it influenced THIS design. 

Since influencing design is one of the main reasons we do TDD, I maintain it is still under the realm of TDD.

Dave Bush replied on Wed, 2014/06/11 - 7:15pm in response to: Mark Unknown

If the reply was to me ... You solved the problem by not having your UI code jammed together with the business logic and database code and etc.  The code was modular. That is not TDD. Modularity enables good TDD.

That helped, yes.  But the code I inherited needed to have interfaces and dependency injection added in order to implement this test.  Again, because I needed to test, the design was influenced.

Mark Unknown replied on Wed, 2014/06/11 - 9:53pm in response to: Dave Bush

Sure. Potato Patato.  Lack of being able to unit test showed that the  code sucked. You modularized (via interfaces/DI ... and probably AOP ;) ) so you could unit test. I modularize so i can use my code for different UIs and via APIs and etc. Prior to TDD being popular, I always envisioned my code being used in multiple ways.  Usually one of those was command line which is much like unit testing. 

I would say that TDD is writing unit tests prior writing anycode. Writing unit tests after is just writing unit tests. ;)

Speaking of sucky code, i saw some today that was written in 2010 that had the ms access db url hard coded along with all the data access in the UI code. Sigh.  Oh. and they used VB.NET. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.