I am trying to get a better understanding of TDD. From a quick google I've found this:
In layman’s terms, Test Driven Development (TDD) is a software development practice that focuses on creating unit test cases before developing the actual code. It is an iterative approach combining programming, unit test creation, and refactoring.
As lately I am trying to focus to make the knowledge gap in my team smaller (small team) I found at least in principle such development flow useful.
Normally in my team we follow scrum development. So we have target for sprints (like features) and we produce tasks and then base on those we have several task stages (like in progress -> review -> done).
However what I often notice is that is that the code is overengineered very often therefore I've been trying to find way to encourage less overengineering and among the benefits of TDD it can be encouraged to write less code.
However my team is a small (like 3 persons) and normally each one of them has very specific skillsets. When I came across TDD my thought was to add an extra stage in our scrum board, say:
unit-test -> development -> review -> done.
Suppose now we have two developers, say
B (as I said my team is small).
A could write the unit-test/unit-tests first, then
B could proceed to the development, knowing that he needs to pass those two tests. In my mind this is also good for
A to gain knowledge on the domain of
B (without going too much in depth) and viceversa.
However what I am afraid of is that adding an official extra stage of development might make things slower.
What I wonder therefore is what are common pitfalls of TDD development, in relationship to small teams.