DEV Community

loading...

Discussion on: Solve this simple problem with TDD

Collapse
michelemauro profile image
michelemauro

Well, Jon Sullivan's answer is quite... interesting. And it's quite, but not completely, different from the path that I took.

In this repository: bitbucket.org/michelemauro/flatten... (sorry, it's Java; I don't do Ruby) you'll find:

  • in the master branch, each commit adds a test
  • in the "mim" branch, each test is merged and solved.

I tried a "the simplest thing that can possibily work" approach, but came out with a really unsatisfying solution because:

  • it's an eager approach: I would prefer a lazy one (one that does not pre-allocate the whole result before returning it) but it didn't seem like "the simplest thing" while writing it.
  • the third test passes without intervention: this makes me think that I wrote too much code the first time. I'll need to work on that.

All in all, my implementation seems very similar to what Jon describes, with the caveat that I don't separate the two responsibilities. I also don't think that the best solution (a recursive, lazy one that can work with infinite collections) can work with this approach, because it requires unpacking a whole sub-array before returning the next element, and that loses the lazyness.

So, this simple question is becoming a really interesting little problem, almost worth a kata. There is a lot to be pondered on.

Collapse
delbetu profile image
M Bellucci Author

Thanks for sharing this!
I faced the same issue, at some early point in the TDD cycles I got stuck and couldn't pass the test without writing the solution that was in my mind.
Anyway, testing first helped me to think about the problem and came out with a solution.
Share my my solution

So it seems that the hard part of TDD is finding The simplest thing that can possibly work