Can TDD be a tester task?

Question

I'm working in a team developing a web application frontend (using Angular) and backend (using Java).

The manager and the team asked me to be in charge of doing TDD (since I am a test automation engineer), so they told me to write TDD scenarios and link them with the code before the developer starts coding new features and re-running those tests after.

Is it normal for a tester to do TDD?

Answer 1

define 'normal'

More seriously, writing (failing) tests before writing code is the essence of TDD and BDD. It means designing the tests and then testable code. The result of writing (failing) tests first is that it actually changes how you write the application code, i.e. to be testable. This results in very different code. Small methods are just one example of the result of this approach. Although TDD implies test first, it often means writing the tests along with the code and going between the two a lot as you discover negative and edge cases to cover. Having two different people (that aren't live pairing) in this will be very slow.

When a different person such as an automation engineer writes tests this is usually going to be in the BDD form of Given, When, Then.

When writing unit tests it is not practical to write the right tests beforehand when you are a different person in a different role because as you write application code you discover approaches and negative/edge test cases and perform refactorings as you code the solution. Separating tests and application code this way will slow the process and lead to lower quality solutions.

Returning to the term 'normal'.
It is probably uncommon but, with the right approach such as high level BDD, it is the right way. If it works for you. However you will need a lot of interaction with the developers along the way. You do not have to implement cucumber btw. You could specify Given, When, Then in tickets for developers to use. I have done this effectively and find that it provides them with the specification they need.

Takeaways:

Ask:

• do we want the automation engineer to specify behavior (declarative) or implementation specifics (imperative).
  For example "User completes the add item form" is declarative behavior where as "User clicks on Complete Item button and database is updated and they are taken to the details page" is imperative behavior, i.e. the "what"(imperative) vs the "how"(declarative).

Answer 2

That's missing the point.

TDD is about fast feedback, so a developer write a checks, runs it, it fails, writes the minimal code needed to make the check pass, runs the check again, this time it passes, goes on to write another check, ...

I suppose two people can't be this in sync unless you work on one computer and share the keyboard.

You can of course treat this as an experiment for some time and then evaluate how it works for you. I'd guess this won't work much and you might even end up finishing your test code after the developer finished his code. That it's obviously not TDD at all.

Answer 3

As others said, it would miss the point.

As Kent Beck says in TDD By Example, TDD is about code design. The tests will drive the architecture of your application, by defining its usage step-by-step.

The suggested situation, in the end, will transform you into a low-level software architect - probably not efficient because you will become a bottleneck for every coding work in the team.

Two alternatives that you may want to consider are:

• Behavior Driven Development: You may want to work together with the rest of the team to define scenarios describing what your software does, and work on creating automation that simulates the users interacting with your software, using these simulations to drive the development of the application itself. Here you are the design of your application's APIs, not its architecture.

• Pair Programming: For the architectural work, you can work side-by-side with the developers, writing with them the tests that will drive the design of the software, this way you are not a bottleneck, but a helper. You can see some of the benefits of pair programming here.

Answer 4

TDD is just about validating something against predefined checks (usually automation checks). The final outcome or goal of TDD is that all tests (predefined checks) need to pass to define the particular User story as done.

Here we define tests parallel/n-1 (means ahead of development) and we won't mark the user story as completed unless all tests pass.

Benefits of this approach is that:

1. Faster feedback as you are doing verification and validation of the development activities against the automated checks
2. Less chance of error fallacy, because you will be developing something that will be strictly validated against predefined checks.SO you wont end up developing something that was not up to the client requirement.

How can you contribute:

TDD as defined is just predefined checks. This checks can be in any test level, developers might be developing unit test first and then start developing the actual component

Your role usually comes in integration and System test level.

As a test automation engineer:

1. Write automated API tests by mocking the actual expected response and then validate these tests against the actual product once product is merged to master
2. For UI start writing test code with mock IDs and then replace it with actual IDs once the product development starts

Please refer to the below answer for more information:

https://sqa.stackexchange.com/a/41769/40022