I'm new to TDD practice and i was wondering if my approach is good from a special case.
I want to program a little software that takes a group of array strings in parameter and split all string in that group.
Example :
{"C - 3 - 3", "M - 5 - 5"} should return { {"C", "3", "3"}, {"M", "5", "5"} }
By cutting out the problem, i started with a StringSplitter and StringSplitterTest with TDD in order to split just one string to an array of string.
After, i programmed a StringGroupSplitter and StringGroupSplitterTest (always with the TDD approach) doing the same thing but with a array of strings (knowing that StringGroupSplitter has a StringSplitter dependency).
So, i remembered the "FIRST" principles of unit tests and in particular the principle of independence saying that a test should not depend on the result of another test.
In my case, the problem is that due to the dependency of StringGroupSplitter and StringSplitter, if only ont test fails in StringSplitterTest, tests in StringGroupSplitterTest will also fail.
So my question is the following : Is my approach to TDD the right one ?
Thanks in advance.
i remembered the "FIRST" principles of unit tests and in particular the principle of independence saying that a test should not depend on the result of another test.
The important idea is that tests should produce accurate measurements regardless of the order in which they are run. If we have a "blue" test and an "orange" test, then we should be able to run either test alone, or both tests in either order, and get accurate information about whether or not our implementation is in agreement with our specification.
Back in the day, coupled tests were a common anti-pattern. When all of the tests worked, then things were fine. But if one test broke, it would be followed by a cascade of untrustworthy results, simply because the preconditions of the subsequent tests might not be satisfied.
Your description of your string splitters does not suggest you have a problem here. If StringGroupSplitter depends on a part of StringSplitter, and you introduce a bug in that part, then having multiple tests fail is normal. This is not the kind of thing we mean when we worry about the anti-pattern.