In software industry, testing is the process of confirming the application works as it is expected to be. Test Last Development (TLD) and Test Driven Development (TDD) are two major testing processes. In TLD, testing is done at end after coding whereas in TDD, testing is done before writing codes. Both of them have their own strengths and weakness. One doesn’t surpass other in all aspects. The objective of the article is to present the strengths and weakness of these processes and help understand both in order to look to opt for better alternative according to the need and situation.
Test last development is a traditional and most common approach of testing where testing is done only after implementation code has been written. But test driven development, test first coding or TDD is a relatively new concept where test cases are written before writing the implementation code . Beck summarizes this as a process of five steps .
- Write a new test case.
- Running test cases should fail the newly written test.
- Now, write enough code to pass the failing test.
- Re-run all the tests and confirm all passes.
- Refactor to remove redundancies
I. PROS AND CONS
TDD and TLD have its’ own strengths and weakness. Due to their contrasting nature, one’s strength is another weakness and vice versa. Their strengths and weakness are discussed below:
A. Time required
Development time is relatively high in TDD. It nearly takes as much as 16% more time than that of TLD . This is because of its iterative process between testing, coding, refactoring and sheer learning curve. Developers have to
constantly move to and fro between code and test cases. They cannot just focus on writing code and then testing but has to focus on writing failing test first and just enough code to pass the test. Moreover it has a steep learning curve. It is discussed below.
B. Learning curve
TDD has a steep learning curve. It is not just a testing technique but a process of test, code and then refactor in forward sequence . Test before coding forces developers to think of test cases before implementation, which they are unfamiliar to. This change requires a lot of practice and discipline. Moreover refactoring comes up with good design principles like use of interfaces, design patterns, abstraction etc. These all comes up with experience, learning and lot of practice. Nonetheless, there is no or very little learning curve in TLD. Developers study and practice during courses in university. It also doesn’t demand refactoring. The task of refactoring is upon developers’ discretion.
C. Maintenance cost and Productivity
TDD decreases the maintenance cost and overall increases the productivity . Maintenance becomes cheaper and easier if the products are highly stable and reliable. Its inseparable relationship between testing and coding recursively is the result of highly reliable and stable product. All codes are vigorously tested during development. There are as many as 52% more test cases as of TLD . This also helps in bug fixing, further development and maintenance by making sure no new bugs are inserted during the process.
D. Code Size
TLD codes have relatively small size. The inclusion of many more test cases in TDD increases the size of the code . But it can be also argued that as TDD only includes the minimum amount of code that are required for the product it has the smallest size possible and test cases are only used during development and not in production environment resulting into much cleaner and better code.
E. Code change
Code changes are common in software development and during maintenance. With TDD, one can ensure that new changes don’t impact the product in an unwanted way. This is by repeated continuous running test cases. Additionally, test cases also act as a good starting point for debugging, which easies change. But it TLD, it is not found to be so. It doesn’t have repeated running test cases to verify every change.
F. Code simplicity
TLD codes are simpler. The cyclomatic complexity of TLD is relatively smaller . This suggests that the codes are linear. Linear codes are easier to understand and code. In contrast, TDD is relatively complex. Complexity is mainly due to the use of various design principles like interface, design pattern, Mock etc.
- II. CONCLUSION
The article has outlined the strengths and weakness of both the processes; TDD and TLD. And we know that no two software projects are exactly same. They differ one other in at least one or many contexts . These contexts play a vital role between TDD and TLD choice as one becomes more effective than other due to its unique strength. They are discussed below:
A. Nature of the Product
Nature of the product confers about product size, duration of development, duration of maintenance, number of releases, customization process etc. .
TDD is advised over TLD if the product is big, has multiple releases, has long life cycle, and expects large number of customization and maintenances. As discussed earlier in the paper, TDD increases overall productivity by decreasing maintenances cost and time. Maintenances and customization requires code change. Code change might bring unwanted behavior in software product. But this can be prevented by TDD due to test cases.
Conversely, TLD is very efficient when product size is small and when there is little time to develop. Development takes place instantly in no time. But TDD has a steep learning curve. Also there are more test cases in TDD which ultimately adds up development time.
B. Team profile and size
People involved during the development of the product are called as team. Team, its profile and its size plays a significant role between TDD and TLD choice.
TDD is more effective over TLD if the team is big, skilled and has high turnover possibilities. Skilled doesn’t have or has little learning curve which doesn’t really matter in terms of the advantage TDD brings into the plate regarding code quality and maintenance. Turnover and big team brings uncertainty during code change. Turnover is usually seen between projects after development phase. Developers associated during development are no longer during maintenances. New members of the team are unsure of the code. In case of uncertainty, test case acts as a best point to start debugging. Also, their codes have high possibilities that it brings unwanted change. It is prevented by the trademark characteristic of TDD, repeated, extensive test cases
Conversely, TLD is effective when team size is small, less skilled and has less or no turnover possibilities. Unlike TLD, less skilled brings steep learning curve in TDD which is undesirable. Small and less or no turnover possibilities kills the advantage of being uncertainty in code as the person involved during development is involved in maintenances. He knows inside out of the code and makes the changes quickly and effectively.
Market mainly talks about the number of customers, constraints to market etc.
TDD is effective and advised if there are many or product has potential for many customers. These products are characterized by very high quality, customization and maintenances. As discussed earlier, TDD has an upper hand in all these areas. Conversely, TLD is effective when there aren’t many customers and quality is not of so much importance as compromise can be achieved with them.
Constraints type nature determines the choice between TDD and TLD. For example: If the constraint is short market time TLD is preferred as they is no learning curve involved. But if the constraint is to adhere to certain standards then TDD is preferred as it will ensure that the no matter what always adhere to the standards.
After all this discussion it is very apparent that, context and process strengths and weakness comparisons and contrast results into wise choice. So looking at today trends and projects, websites and mobile applications with small in size and life cycle can gain tremendous advantage from TLD while long service based products with potential large number of clients and long life cycle will be benefited by the use TDD.
. Beck, K. 2000. Extreme Programming Explained. Addison Wesley.
. B. George, L. Williams, A structured experiment on test-driven development, Information and Software Technology 46 (2004) 337–342.
. M.M. Mueller, O. Hagner, Experiment about test-first programming, IEE Proceedings – Software 149 (5) (2002) 131– 136.
. H. Erdogmus, M. Morisio, M. Torchiano, On the effectiveness of the test-first approach to programming, IEEE Transactions on Software Engineering 31 (3) (2005) 226–237.
. Beck, K. 2003. Test-Driven Development: By Example. Addison-Wesley Professional.
. B. Turhan, A. Bener, P. Kuvaya, M. Oivo, A quantitative comparison of test-first and test-last code in an industrial project, in: A. Silliti et al. (Eds.), XP 2010, LNBIP 48, Springer-Verlag, Berlin, 2010, pp. 232–237.
. Kai Petersen, Claes Wohlin: Context in industrial software engineering research. ESEM 2009: 401-404.