Will writing unit tests block developers from coding?

Question

We are about to implement TDD in our software company and we met some serious questions.

As you know, this is the TDD life cycle:

1. Add a test
2. Run all tests and see if the new test fails
3. Write the code
4. Run tests
5. Refactor code
6. Repeat

We have many development tasks, with nice and readable user stories in the backlog. I just don't know "when" we should write unit tests (and acceptance tests) during the development. I know TDD said we should write tests before code, but here is my problem:

If our testers (currently there are only 2 testers) start writing automated unit tests before development process, then what should developers actually do until writing unit/acceptance tests finish (there are about 8 developers)? Should they wait for unit tests or they should start development process right away (and as soon as writing unit tests finished, they can test their software afterward)?

Another scenario is to involve everyone to start writing unit tests/acceptance tests. Then what's the point of being a "tester"? I mean in this case I won't have a clear job description for our testers as we were thinking about they will write unit tests/acceptance tests and after that developers will start writing codes. If developers also write unit tests, then what's the point of having special testers in our team and should we replace testers with developers?

Sorry if my question seems ridiculous to you. We are just in the beginning of our process and need to clear such things in our company.

Answer 1

The TDD cycle is more a development cycle for a developer, to quote James Shore, The Art of Agile, Test-Driven Development chapter:

Programmers new to TDD are often surprised at how small each increment can be. Although you might think that only beginners need to work in small steps, my experience is the reverse: the more TDD experience you have, the smaller steps you take and the faster you go.

If you really want testers to be involved pair programming might be a solution, another quote:

Pair programming helps. While the driver tries to make the current test pass, the navigator should stay a few steps ahead, thinking of tests that will drive the code to the next increment.

I think Test-driven unit-testing could be very technical, maybe testers can better focus on preparing for customer-facing tests and or exploratory testing. Although reviewing the test-cases that come out of the TDD cycle might also be very valuable.

But your suggested cycle where someone else writes the unit-tests first seems very slow, unless you do it in pairs. One person writes the test, the other implements the code. Now switch. This works pretty well.

I think what you are looking for is Acceptance Test-Driven Development here you write scenario's with Given/When/Then in a human-readable DSL upfront. This is also called Behavior Driven Development. Here it makes way more sense to write the tests upfront. Still, the whole team should help to define the behavior. You could use requirement workshops like described in the specifications by example of the LeSS chapters.

Avoid dependencies and people waiting on each other. Some should be the guru's, but everyone should be able to do any work in the whole development life-cycle. Minimize the Bus-factor.

Answer 2

I'd plan it this way:

The specific tests that are written 'before the code' are unit tests that are written by developers just before they write the actual code. It should only take 5-20 minutes to write a simple test. The test is written, the code is written for it and then the test is changed or the next test is written and then more unit level code is written. This happens on the time scale of seconds to minutes.

Don't get too hung up initially on writing the unit tests before the code because a) you may not be familiar enough with the approach to do it smoothly and b) sometimes its hard to do. Initially focus more on every function and block of code currently being written having tests + code when that change is added in to the master code base. Over time developers will be able to write more and more tests before the code itself.

When the feature that uses all the components above is ready (time scale of hours to days) then QA can start testing it manually and also by writing automated end-to-end feature tests.

What can QA do before the feature is ready? Plenty of things - pair on test plans with developers, learn the domain, work on test cases with the product owner, etc.

I would also modify your development tasks a little as follows:

• Write simple unit test(s) with application code to ensure that it fails (important!)
• Write working code that will then make just that new unit test pass
• Repeat above two steps until the new or changed feature is complete
• Refactor as desired
• Code review for new/changed unit tests & code by developers and QA
• Ensure that all the other unit tests still pass or go back to first step
• Ensure all tests (unit, integrated, features, performance, etc.) pass or fix them and/or the code
• Refactor as desired
• If new integrated / feature / performance tests are needed, write them
• Code review for new tests & code
• Refactor as desired
• Release

This also emphasizes that initially you are working on just the new test and code and not even running other tests until that is done.

Also consider branding the testers who write actual test code as performing QE (Quality Engineering) over QA (Quality Assurance) which tends to have more of a connotation with manual testing (only).

Approach all of this as a team. Work in the same physical space. Talk about the functionality, the design patterns, the tests and the code as a team. Make sure you don't have physical or mental walls that are separating 'testers' from 'developers'. Try using language that first defines everyone as engineers and then you can have mention of the those who focus on the testing area (especially reflecting actual users) and those that focus on the unit code and tests (traditional developer roles).

You will be looking to hire for the role SDET - Software Development Engineer in Test. You should aim to have at least one experienced engineer to lead and then you can have more junior folks

See also:

Who writes stories and tests in Agile? BA or tester?

Fitting regression testing in a Agile/ Scrum development cycle

Answer 3

If developers also write unit tests, then what's the point of having special testers in our team and should we replace testers with developers?

Unit testing is not the only kind of automated testing. Integration tests, performance tests, scalability tests, and fault tolerance tests are all examples of automated tests that are not unit tests and that a coder/tester could own.

Answer 4

Unit tests should be written by developers. Unit tests are very close to the core code and developers have intimate knowledge of how units should work. testers are usually more removed from the deep innards of the core code and they will not be ass effective writing unit tests as core developers are.

Acceptance/integration/end-to-end tests do not require this intimate knowledge if system innards, and can be effectively written by testers. It is a different set of eyes reading the requirements and writing the code to exercise the code according to requirements. You can start while development is underway, but you can finish only after development is finished.

Answer 5

Let me answer your queries in a different way i.e. not by looking at the number of testers and developers and how to utilise them during the initial phases of development cycle. TDD and TFD tries to emphasise on a very important aspect of SDLC which in the long term helps in reducing testing costs and helps to launch a product on time if not sooner.

Whichever Testing model an organisation follows in majority of the cases high number of defects are identified during the Integration/E2E testing phases which may be down to multiple factors such as more live like infrastructure which was not available during unit test, more real data used for testing and also that all combinations of user journeys/ use cases were not captured/missed in the unit tests or may be not thought of. In such cases it adds a lot of time to the entire delivery schedule as the defect identified will then have to go back to the dev teams, fixed, unit tested and released to the integration test team for final signoff. In the above example the dev teams did the same thing but as opposed to TDD approach they developed and tested the scenario at a much later phase, hence TDD is gaining momentum in complex deliveries to identify bugs at an earlier phase itself.

All organisations will have to move to DevOps and TDD and tweak these to suit their requirements to achieve their target dates. It is a culture that all need to inculcate in all the teams involved in the SDLC.

Now looking at your particular query which is the utilisation of a team of 2 testers and a team of 8 developers.

Split the team to two (don't have to consist of equal size) with each tester in each team. Testers generally have more analytical approach to derive test combinations whereas the developers have more insight on how quickly he/she can create a stub/API to simulate it. The change in culture in TDD and DevOps is we should not differentiate and going forward the aim should be to classify an individual based on what tasks he/she needs to perform at that point that helps to utilise the team efficiently and also shares knowledge across all. All the tests of a particular module need not be derived on the same day i.e. if a certain percentage of tests are derived then the actual development/coding can start (which can be done by team 2) while the identification of the remaining areas continue.

Hope this will help you and all the best for your project.

Answer 6

Testing is coding!

Or at least it should be in most environments today. Automation code that supports application can be hard to get right. However it shouldn't be seen as 'optional' and separate from coding.

Now I guess the point maybe should have been (and probably was), would 'automation development' potentially slows down the delivery of 'application development'.

Or should I say 'slow down the development and rollout of untested application features.

Yes. It would slow them down.
It should.
That's the whole point.