While talking to one of the client stakeholder, I came across this interesting term as Test-Along Development.
Following are two different techniques I came across as common way of writing unit test:
- Test-driven development where we write unit tests first and then write enough code to make unit tests pass
- Write unit tests at the end once you are done with the development.
Both of the above techniques presented enough challenges to the software developers. Some of them are following:
- Test-driven development:
- In agile development, in 2 week sprints, the design took much longer than 2-3 days. Thus, doing test-driven development was found to lead carry-overs for sprint given on site-offshore model of development where communication used to take additional time.
- Lack of knowledge of TDD and associated software development practices
- Writing unit tests towards the end
- Lack of time due to delay in feature/functionality completion
- Inability to do decent test coverage due to attention to various different flows of a use case
So, What is Test-Along Development (TAD)?
Simply speaking, TAD is writing unit tests as you are developing the code. This technique is simpler than TDD. However, this is still challenging. Developers still have to plan about unit tests much earlier and, for that reason, have to understand the requirements more diligently.
- Agentic Reasoning Design Patterns in AI: Examples - October 18, 2024
- LLMs for Adaptive Learning & Personalized Education - October 8, 2024
- Sparse Mixture of Experts (MoE) Models: Examples - October 6, 2024
Are you saying that in TDD *all* unit tests should be written before the code? My understanding of TDD (and the “version” that I practice) is what you’re calling TAD. I would never attempt to write a full suite of tests in advance of any code, unless the suite was expressed entirely in pseudo-code.