I have been in the software development industry since 2010, working on enterprise product development using ADF. I am usually keen on learning about software design and emerging technologies. You can find me hanging around in the JavaRanch Forums where I am one of the moderators. Apart from Java, I am fascinated by the ease of use and simplicity of Ruby and Rails. Mohamed is a DZone MVB and is not an employee of DZone and has posted 58 posts at DZone. You can read more from them at their website. View Full User Profile

My First steps in Test Driven Development- A Win-Win Strategy

05.03.2012
| 6072 views |
  • submit to reddit

Agile practitioners talk about Test Driven Development(TDD), so do lot of developers who care about their code quality and workability. And I once upon a time, not so long ago managed to read about TDD. The crux of TDD as I have understood is:

  1. Write Test, and fail
  2. Code, make the tests succeed
  3. Automate the tests
  4. Refactor the code to improve the quality
  5. Repeat

Pretty easy to understand. A annoyed developer shouts- “A developer writing tests? How can you expect us to develop and test and yet finish the feature in time?”. After all developers dont want to do the boring testing work. I have been a developer for around 2 years know and there were times when I reacted that way, during those initial days. But with time, I have started to understand the crux of software development. And this time around I thought of trying out TDD.

My work involves wiring up the data in the db with the UI using an Java EE web framework- A typical web application work.

Let me explain my testing strategy before I adopted TDD:

  1. Write the complete code which includes- PLSQL procedures, Java code to invoke PLSQL procedures, Java code for the UI bindings and the JSP page itself.
  2. Manually test the functioning of the db layer and the UI layer code. It involves navigating to the page and then testing various operations. In this case both the UI issues and the Backend code issues would crop up.
  3. As I would play around with the UI further, I would unearth few bugs in the code, otherwise write a selenium test to automate testing of a few use-cases.

With the above 3 steps, I spent a lot of time-

  1. waiting for the backend code to compile and the restart the server for the UI to reflect the changes. Even if its a simple 1 word/1 statement change I had to wait for approximately upto 5 minutes and in some cases 8 minutes. While I would wait for this to restart, I would have lost focus to some other task and there by take sometime to come back to the main task.
  2. trying to debug and find out if the exception/bug is due to the UI code issue or the backend code issue.
  3. in waiting for the pages to load and navigate through the pages to the right page.

Ok, those were the pre-historic times. Now coming to the Modern Age. I thought TDD would not have been possible in the kind of work I do, it was because I wrote a badly coupled backend and UI code. I couldn’t think of ways to test my back end code independently and then move to the UI code and then test it via selenium tests. Keeping aside these notions, I gave it a shot. I know I wasn’t very close to the actual TDD, but I felt somewhat closer.

  1. I had a fair idea of how to implement the logic, created a basic implementation and let it compile successfully.
  2. Created a few data population tests to get the kind of data to be used for the testing.
  3. Created JUnits to tests the basic functionality. Mostly in terms of the correct execution of PLSQL procedure via the Java API.
  4. Updated the JUnits to add more tests to test out the actual functionality required and updated the code to implement those functionalities.
  5. Refactor the code to remove bad smells and then run JUnits to see to it that nothing is broken.

The reasons why I felt excited, why I felt it was a Win-Win strategy:

  • I began to think in terms for the user of the API more than its creator. This kept me away from adding hacks which could fix the issue but would be difficult to test. This tremendously improved the code structure then what I had written before.
  • No server restarts, no wasting of ~ 8 minutes per restart, no wasting of navigating to the pages. I just had to edit the code, run the junits and see the tests decide the fate. This is more useful for the backend code I have written.
  • No loss in focus as I am deeply involved in Code-Test cycles.
  • Sense of achievement as I see the tests show up green bars.
  • Possibility of creating a code with good unit tests to test the backend features, which also helps in refactoring the code more easily.

Now I just have to write the glue code for the UI and the backend and test the glue code via the selenium tests.

Anyone had any similar experiences when they started to use TDD?

Published at DZone with permission of Mohamed Sanaulla, 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

Wujek Srujek replied on Fri, 2012/05/04 - 3:21am

As for the restarts taking minutes: I suggest you take a look at JRebel, which is a wonderful tool capable of reloading classes way beyond what HotSwapping does. For what they offer, the price is negligible.

I am not affiliated to JRebel or ZeroTurnaround in any way, I am just a delighted customer of theirs.

Mohamed Sanaulla replied on Wed, 2012/05/09 - 1:03pm in response to: Wujek Srujek

Yes, I am aware of JRebel. But I dont think we would be using it OR atleast I dont think I can influence them to use it. We did have the hot deployment kind of feature, but that was only for POJO changes and very limited functionanity and hence it never took off and I never tried that.  

Comment viewing options

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