Test Driven Development Pitfalls

Test Driven Development (TDD) has been one of the most adopted agile practice. It has bring back the importance of unit testing, but also mostly remind that people have to think about what their code really want to achieve before writing it.

Test-driven development that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case, then produces the minimum amount of code to pass that test, and finally refactors 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. However, how simple this might appears, it is not easy to perform this approach successfully on the long term.

Two interesting articles published in the Methods & Tools free software development magazine might help you  to do this. Test Driven Development (TDD) Traps by Jakub Nabrdalik presents all the issues that a agile software developer might face when trying to apply TDD and explains how to overcome them. Writing Testable Code by Isa Goksu explain how to write a code that will be easy to test... and then easy to refactor. This two articles are a good read for every software developer that believes in the power of unit testing to achieve quality in software code.

Software Testing and Quality in the Summer 2011 issue of Methods & Tools

Methods & Tools - the free e-magazine for software developers, testers and project managers - has just published its Summer 2011 issue with the following articles:
* Continuous Delivery Using Build Pipelines With Jenkins and Ant
* Everything You Always Wanted to Know About Software Measurement
* The Art of Mocking
* Restructure101 for Java  - Refactor Your Software Architecture
* Maven - Java Build Management
* Automated WebTesting with Selenium RC
* Liquibase - Open Source Dababase Version Control
55 pages of software development knowledge that you can download from http://www.methodsandtools.com/mt/download.php?summer11

Agile, Project Management and Software Testing in Spring 2011 Issue of Methods & Tools

Methods & Tools – the free magazine for software developers, testers and project managers – has just published its Spring 2011 PDF issue with the following articles:
* Automated Acceptance Tests and Requirements Traceability
* Managing Schedule Flaws using Agile Methods
* User-Centric Design and the Power of Personas
* Complexity Theory for Software Developers
* Build Patterns to Boost your Continuous Integration
* GivWenZen – Behavior Driven Development for FitNesse
* Celoxis – Web Based Project Management
* Tellurium Automated Testing Framework
* Apache CXF
* RSpec Best Practices
* Maven Plugins
Download 80 pages of software development knowledge

Software Testing Dojos in Winter issue of Methods & Tools

Methods & Tools – the free e-magazine for software developers, testers and project managers – has just published its Winter 2010 issue with the following articles:
* Non-Functional Requirements: Do User Stories Really Help?
* Software Testing Dojos
* Process improvement, The Agile Way!
* Tool: Apache ServiceMix
* Tool: Apache Camel
* Tool: ArgoUML – Open Source Unified Modeling Language

Download 45 pages of software development knowledge

Agile, project management and software testing in Fall issue of Methods & Tools

Methods & Tools – the free e-magazine for software developers, testers and project managers – has just published its Fall 2010 issue with the following articles:
* Distributed Teams and Agile – Managing Global Agile Projects
* Decomposition of Projects: How to Design Small Incremental Steps
* Source Code Analysis in Agile Projects
* The Core Protocols, an Experience Report, Part 2 – Tools for High Performance Teams
* tinyPM – Agile project management
* Junit – open source Java unit testing
* Bromine – open source Web testing
* Agilefant – open source Agile project management
* SoapUI – open source Web testing

Download 70 pages of software development knowledge

Can Developers and Testers Love Each Other?

After the results of a previous poll focused on functional testing automation, I wondered if there was still a great divide between the worlds of development and functional testing. So I did this follow-up question to check who was performing the functional testing.

This poll was trying to determine who perform functional testing in your IT department? Here are the answers:

Software developers	15.4%
Specialized testers:	37.4%
Both	36.2%
Nobody: functional testing is done by end-users	11.0%

Participants: 409
Ending date: March 2010
Source: Methods & Tools

As you can see, in close to 50% of the cases, developers are not involved in functional testing. Trying to find the causes of this situation, I asked for explanations in various testing and agile groups on LinkedIn. Two explanations came out:

Developers do not master functional testing tools. These are specialized tools that use mostly proprietary scripting languages, even if some new tools like the WatX family use the same programming language to create tests. Then validation needs to be independent from development. Following this rule, people said that the role of analyst and functional tester can be mixed in software development projects, but you cannot ask a developer to test its own work. This opinion has been expressed both in software testing and in agile focused groups.

This situation is also representative of the mistrust relationships that often exists between development and testing teams in software development organizations and apparently Agile hasn’t’ changed it. If few people will deny the fact that the customer is the ultimate judge to validate an application, QA people often describes developers as careless people that are unable to challenge their own work and developers see QA people as disconnected from the project reality and slowing the delivery of applications to users. Having worked in large software organizations, I have sadly witnessed the truth of both cases: developers that don’t test enough their work and QA people that don’t know the domain of the application or built process that could be nice looking in theory, but practically not adding value to the software delivery.

I strongly favor the case when developers take the full responsibility from understanding the requirements to deliver the application to the user. The more specialization you involved in the process, the more information you loose when you try to transmit it. Understanding the requirements allow the developer to take the full responsibility of its code. If it cannot be trusted for functional testing, then it should be the same for unit testing…. and then it should just not be trusted as a developer. I understand that this vision could sound a little bit utopian due to the reality of human behavior, but to me it is not more idealistic than thinking that users can give you the right requirements and have enough time and knowledge to validate the delivered application.

Resources

Functional Testing Tools Directory

SQA Zone

Testing TV

Agile + Software Testing & Quality in Methods & Tools Spring 2010

Methods & Tools is a free e-magazine for software developers, testers and project managers. Spring 2010 issue has just been published with the following articles:
* Using WatiN to Leverage Common Elements in Web Testing – structure your Web testing efforts
* Five Symptoms of Mechanical Agile- detect agile adoption issues
* Writing Testable Code – testable code is better code
* Model-Based Testing Adds Value – a quicker way to functional testing plans
* Tool: Sonar – monitor code and project quality
* Tool: Express Agile Project Management – a simple tool for Scrum
* Tool: Apache JMeter – for load and functional testing

60 pages of software development knowledge that you can download from http://www.methodsandtools.com/mt/download.php?spring10

Functional Test Tools: Adopted but not Used?

A recent Methods & Tools survey tried to evaluate the usage of tools to automate execution of functional software tests. A similar poll was conducted in 2005 and it was interesting to compare the results.

http://www.methodsandtools.com/dynpoll/oldpoll.php?FuncTest2

Unit Testing Still Widely Informal

A recent Methods & Tools poll examined how organizations perform unit testing. Is it an informal activity that is done before integration if there is some time left after programming or is it the key element of the development effort? The question was: How is unit testing performed at your location?

Proportion	2008	2006
Unit testing is not performed	17%	13%
Unit testing is informal	40%	46%
Unit tests cases are documented	9%	11%
Unit tests cases and their executions are documented	14%	16%
We use a Test Driven Development approach	20%	14%

Participants: 384 (2006:460)

Ending date: October 2008 (February 2006)

Despite the fact that the number of TDD adopters has grown nicely since the previous survey, you can notice that unit testing is still widely conducted in a informal manner, when it is not simply ignored by developers. This could sound weird when many people announced a general adoption of the agile approaches, but the results of our survey are similar to many other polls on the same topic.

Comparing the two surveys, it seems that people that were already doing unit testing formally have switched towards a TDD approach. People that don’t do unit testing have different reasons. Some will consider simply that they don’t add value to their development process, which is sometimes difficult to believe. For others, it is the lack of time, a reason more easier to understand ;o) Many complains that unit test are hard to write, but creating a good unit test is a proof that you understand what your code should do. I agree however, that it could be difficult to maintain large libraries of unit testing scripts if requirements are changing constantly. In the “good” reasons not to perform unit testing, some thinks for instance that the client side of Web application is not suited for this kind of tests. There are also some organizations that have separate testing teams. Their developers will rely entirely on the QA guys to test their application. You can also consider that when the software has a very limited life expectancy, it is not worth making unit tests.

More than 500 Links in SoftDevLinks.com

SoftDevLinks.com is a new general directory for software developers, testers and managers. Launched in June, it has achieved in September more than 500 links. If you have a blog, a web site, distribute a tool or work a consulting company related to software development, do not hesitate to add (for free) your links in this directory.

http://www.softdevlinks.com/

The Three Rules of Test Driven Development

Over the years I have come to describe Test Driven Development in terms of three simple rules. They are:
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

You must begin by writing a unit test for the functionality that you intend to write. But by rule 2, you can’t write very much of that unit test. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code. But by rule 3 you can only write the production code that makes the test compile or pass, and no more.

If you think about this you will realize that you simply cannot write very much code at all without compiling and executing something. Indeed, this is really the point. In everything we do, whether writing tests, writing production code, or refactoring, we keep the system executing at all times. The time between running tests is on the order of seconds, or minutes. Even 10 minutes is too long.

Robert Martin

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Besides these rules and independently of an agile approach, I always like as a developer being able to verify quickly my code, because it makes much more easier to find all the errors I do ;o)

New Software Quality Assurance Portal

The Software Quality Assurance Zone is a repository for resources concerning software testing (unit testing, functional testing, regression testing, load testing), code review and inspection, bug and defect tracking, continuous integration. The content consists of articles, news, press releases, quotations, books reviews and links to articles, Web sites, tools, blogs, conferences and other elements concerning software quality assurance. Feel free to contribute with your own articles, links or press releases.