I used to believe that unit tests are popular and usually one step further than implementation. I know that a lot of people are not convinced to following TDD approach but I don’t understand that someone thought that no tests are required.

I have fallen in love with TDD since it helped me to save a lot of time. It was some time ago when I realized how useful it was. Unfortunately, I didn’t keep information about the case what bug had been detected then, but perfect example happened in the project which I’m working on now. It’s a good thing that the simplest example are the best to show the essence of issue.

The problem was rather easy, there were two different sets of TrackItem – the smallest unit in tcx format (workout is composed of a lot of TrackItem ). In this case I wanted to find those items from both sets which were placed in a common period. I started from three unit tests.

[Fact]
public void FindIntersection_SetsWithIntersection_2ItemsIntersection()
{
  var firstSet = GetTrackItems(4);
  var secondSet = GetTrackItems(4, offset : 2);</code>

  var sut = new TrackIntersectionService(firstSet, secondSet);

  var result = sut.FindTrackIntersection();
  result.Primary.Count.Should().Be(2);
  result.Secondary.Count.Should().Be(2);
}

[Fact]
public void FindIntersection_SetsWithoutIntersection_NoIntersection()
{
  var firstSet = GetTrackItems(2);
  var secondSet = GetTrackItems(2, offset : 2);

  var sut = new TrackIntersectionService(firstSet, secondSet);

  var result = sut.FindTrackIntersection();
  result.Primary.Count.Should().Be(0);
  result.Secondary.Count.Should().Be(0);
}

[Fact]
public void FindIntersection_SetConteinedIn_3CommonItems()
{
  var firstSet = GetTrackItems(5);
  var secondSet = GetTrackItems(3, offset : 2);

  var sut = new TrackIntersectionService(firstSet, secondSet);

  var result = sut.FindTrackIntersection();
  result.Primary.Count.Should().Be(3);
  result.Secondary.Count.Should().Be(3);
}

Ok I had three red dots in tests explorer, it was a time to start implementation.

public TracksPair FindTrackIntersection()
{
  DateTime maxCommonTime = FindMaxCommonTime();
  DateTime minCommonTime = FindMinCommonTime();

  new Func<TrackItem, bool>(n => n.Time >= minCommonTime && n.Time >= maxCommonTime);
  firstFiltered = _first.Where(intersectionFilter).ToList();
  secendFiltered = _second.Where(intersectionFilter).ToList();

  CreateIntersectionTrackPair(firstFiltered, secendFiltered);
}

I ran tests, and what a surprise it was not passing. I just took a look into the code which had been written a few minutes earlier, and found the bug. Simple typo. It would have been very funny debugging if I hadn’t written those tests, which detected the problem as early as possible.

var intersectionFilter = Func<TrackItem, bool>(
            n => n.Time >= minCommonTime && n.Time >= maxCommonTime);

In this simple example, I wanted to show you the fact that time spent on writing tests is never wasted. If you don’t make any mistake in implementation you are protected from breaking changes in the future but if you made a mistake, you would waste a lot of time on looking for where is the bug. In this case I was pretty sure where I did something wrong and could fix it very fast. In case whole function is tested by QA together, you always have to check at least a few places.