Intermediate functions: To test or not to test?

[Cohen-Carlisle]

My two cents:

I just finished Ruby's crypto-square and I let the tests drive the implementation without much thought at all as to what I was actually doing. I think this was mostly because I was unclear on some portions of the readme. Then at the end I had a pretty big jump to make to get the ciphertext working and I hacked it together in an ugly fashion.

I definitely think the tests were driving the implementation too much on that particular exercise. I didn't really have to think until near the end, and by then I had implemented things on autopilot in way I didn't actually like much.

So from that experience, I say "NAY" to testing intermediate functions.

Devil's Advocate:

Testing intermediate methods allows beginners to get a start where they might otherwise hit a wall. I should be practicing red-green-refactor instead of letting the tests of intermediate functions drive the implementation in a way I didn't like.

Counter Devil's Advocate:

I concede I should have practiced red-green-refactor. However, the fact remains that testing intermediate functions forces me to take certain approaches I might not otherwise have taken.

[kytrinyx]

So from that experience, I say "NAY" to testing intermediate functions.

I would prefer to not drive the implementation. There have been a number of improvements over the past year or so where exercises were changed to allow much broader approaches.

For beginners, perhaps we should simply find a larger number of simpler problems that they can tackle.

[petertseng]

I've said my piece on these before on largest-series-product (where I had tracks remove their tests of intermediate functions).

You can refer to previous discussions on crypto-square as well, could be useful for context.

I'm a bit pressed for time so I don't have much else to say other than to bring in some history.

[Insti]

I say "NAY" to testing intermediate functions.

The tests that Exercism provides should be acceptance tests that check that the solution solves the problem.

Writing tests is in itself an important part of coding and people should be encouraged to write their own intermediate tests.

[kotp]

I think letting people know that they can in fact edit the test file that we give them is good. I think the first iterations submitted are ones that pass the tests as given, anything extra is honey derived from ideas and discussions.

Those modified tests are also able to be shared in the iterations... such as this shared test in the iteration.

[kytrinyx]

I think that we're all in agreement about not creating overly-prescriptive test suites.

As a result, I think that we can consider this particular discussion "solved" and close it.

I have opened an issue at #44 in order to discuss/clarify a process for fixing test suites when we find exercises that dictate specific implementations, and also to come up with documentation that we can point to rather than digging through history to try to remember what has been said and done previously on the subject.

Writing tests is in itself an important part of coding and people should be encouraged to write their own intermediate tests.

This is a good point. I think that there's an interesting meta-question that we've not yet tackled head on, and that is what guidelines should we give to people who use exercism with respect to how they can/should approach solving the exercises.

Should we close this and open a separate discussion thread for the second topic?

[kotp]

I have suggested several times that people modify the tests to explore where to go with the exercise to get more features drawn out, such as the Raindrops one, where when they solve using prime numbers, but it only requires factors, rather than prime factors.

I think it should be made clear that the tests are (meant to be) definitive, but not untouchable.

[Cohen-Carlisle]

Closing this as a consensus has been reached that intermediate functions should not be tested (or, in other words, the tests should not drive implementation).

[petertseng]

nominating for policy label.