When creating mobile applications, you need to start with concrete requirements, and deliver a thoroughly tested application. Unlike web applications, if your users face an error on their mobile, you can’t really push a fix for it. You have to re-publish the mobile application and hope your users download it.
This is why robust testing techniques are of prime importance in mobile application development.
TDD, or Test Driven Development, is a programming structure where developers first write all possible test cases – and then develop code to pass each test case. With TDD, code is more reliable and easily maintained. A simple Google search shows you how popular it is among developers, and sometimes even businesses. However, is TDD still relevant? Let’s find out!
In 1996, Chrysler was building a payroll project called Comprehensive Compensation System (C3), but like many enterprise projects, it was in continuous development and never saw the light of day (it was actually scrapped entirely when Chrysler was acquired by Daimler-Benz in 2000 – but that's another story!).
Chrysler brought in Kent Beck, a prominent Smalltalk practitioner, in order to optimize the system and improve its performance. As Beck worked on the project (which was being built in the C3 language), he realized that there were some challenges in Chrysler’s development process, and he used the opportunity to make some changes.
In 1999, Beck wrote a book about his methodology, which he called Extreme Programming (XP). In his book, Extreme Programming Explained, he defined many constructs that would go on to become popular tenants of modern programming and development practices – the most famous of which is TDD (Test Driven Development).
The 12 Core Practices of XP are:
1. Customers define application features with user stories.
2. XP teams put small code releases into production early.
3. XP teams use a common system of names and descriptions.
4. Teams emphasize simply written, object-oriented code.
5. Designers write automated unit tests upfront and then run them throughout the project.
6. XP teams frequently revise and edit the overall code design, a process called “refactoring.”
7. Programmers work side-by-side in pairs, continually discussing each other’s code.
8. All programmers have collective ownership of the code and the ability to change it.
9. XP teams integrate code and release it to a repository every few hours. They never hold on to it for more than a day.
10. Programmers work only 40 hours per week; there’s no overtime.
11. A customer representative remains on-site throughout the development project.
12. Programmers must follow a common coding standard so that all of the code in the system looks like it was written by a single individual.
Kent Beck often describes his role as “rediscovering” TDD rather than creating it. In fact, some of these practices were used as early as the 1960’s in NASA’s Project Mercury, the first human spaceflight program of the United States.
So, if TDD was used back in the 1960’s, is it still relevant in the 21st century?
Opinions in the Industry
In 2014, David Heinemeier Hansson (aka DHH) posted a comment that set off a chain of discussions and tweets all over the internet: “TDD is dead. Long live testing.”
In his article (which he linked in his comment), he argues that TDD causes architecture design damage because it forces developers to think of all of the situations where the code could fail without actually writing the code itself. It is sometimes counterintuitive to the developer, and sometimes counterintuitive to the process; yet it is seen as almost a crime not to follow it, forcing people to think that TDD is the only correct way to code.
He reminds us that a common TDD maxim is: “code that’s hard to test in isolation is poorly designed.” In this case, “isolation” means that a unit of code must be independent and separated from data stores to be tested. This means that you need to create mock objects – mocks of all objects in your system that can act as data store objects although they are not actually data store objects themselves. This allows you to test just one "unit" of your business logic without testing the data store itself.
In reality, however, this forces you to maintain not only business logic and tests, but also the mocks themselves, thus undermining the design of your application (as DHH details here). This outlash against TDD led to a series of video debates between DHH, Kent Beck, and Martin Fowler. They are quite interesting and, of course, and very opinionated. You can watch them here:
You can also read this blog for a complete run down.
Ian Cooper takes a more pragmatic approach to TDD in his popular talk, "TDD, Where Did It All Go Wrong." He says that TDD was propagated incorrectly, which slowed developers down; they seemed to think that TDD meant testing every miniscule functionality, whereas in reality, it means testing functionality in the smallest possible unit. Cooper claims that one way to avoid this is to shift from testing the internal technical details to testing user-facing behavior instead.
Conclusion
In my personal experience, I've seen many organizations and "professionals" claim that TDD is absolutely necessary for software development, but I've never seen it strictly mandated. It is still up to the developer or team to follow through on it. This leads to situations where developers think, "I'm done but I just need to add tests now."
I sympathize with this. As a developer myself, I've noticed that TDD often slows me down, hinders my creativity, and seems increasingly redundant as my career progresses. I am much more interested in solving problems than in thinking of all the ways that things can fail and then writing code just to satisfy these scenarios. In reality, I could encounter entirely different test cases when I code.
There is an excellent article on TDD and productivity on Dev.to, and I strongly recommend that you read it before forming your own opinions.
So maybe TDD isn't dead -- it's just due for a much-needed face lift!
Swaathi Kakarla is the co-founder and CTO at Skcript. She enjoys talking and writing about code efficiency, performance and startups. In her free time she finds solace in yoga, bicycling and contributing to open source.
