Exercises without a test suite?

[pminten]

If you look at BDD an essential part of that is that you write both the code and the test suite at the same time. You can't do red-green-refactor with an existing test suite because you'd only end up at green when the whole job is done.

Would it make sense to have a few exercises that don't have a test suite at all, that are explicitly about applying TDD/BDD principles? Such exercises would of course have to have README's that are very clear about the requirements, but that's quite doable.

[kytrinyx]

People have asked about it before. I think that it's a useful thing to practice, but I have no idea what a good practice problem would look like for TDD. In my experience people refactor too early, before they understand the problem that they have. I don't know how we would critique TDD, since that's the process, not the result. I'm sure we could critique the code and the test suite, but I don't know if that would help improve the TDD process itself.

I'm very open to introducing some problems that explore this and seeing where it goes.

[pminten]

Yeah, need to think about it some more.

Unfinished thought: you kinda want a series of snapshots taken at each red/green and green/red transition - and diffs between them - to see the process. Maybe some command that runs the tests and on state transition makes a snapshot. A variant of that could be useful for recording the process of a refactoring exercise as well.

Katrina Owen [email protected] schreef op 27 april 2015 21:51:17 CEST:

People have asked about it before. I think that it's a useful thing to
practice, but I have no idea what a good practice problem would look
like for TDD. In my experience people refactor too early, before they
understand the problem that they have. I don't know how we would
critique TDD, since that's the process, not the result. I'm sure we
could critique the code and the test suite, but I don't know if that
would help improve the TDD process itself.

I'm very open to introducing some problems that explore this and seeing
where it goes.

---

Reply to this email directly or view it on GitHub:
#80 (comment)

[kytrinyx]

I like this idea, but after having spent a lot of time thinking about how to clarify the scope of Exercism, I've decided to define this as being out-of-scope. I think that it would make a very interesting (and focused!) stand-alone project, and if it existed I would absolutely recommend it to people (and link to it from exercism).

[petertseng]

Shall we do something with https://github.com/exercism/x-common/blob/master/counter.md ? Deprecate?

Go is the only implementing track

[kytrinyx]

I forgot we had this. Hm. Yes, I think maybe we should deprecate it, to keep the scope simple. Counter-arguments?

[kotp]

I think the points to consider on this is:

• Has anyone solved this yet on Go?
• What has been the response?
• Does it hurt to be there until at least 5 people get there and solve it or 15 people get there and do not solve it (indicating no interest, perhaps.)
  • 5 and 15 above are arbitrary numbers of people

I suspect if @kytrinyx forgot about this issue, then perhaps people simply aren't doing this in the Go track? (I haven't been doing anything as far as that track goes though I really should.)

[petertseng]

Six unarchived submissions; one of them is one I just submitted just so I could check this number (I could look through archived submissions and try to count them but there's no guarantee I'd get them all)

[kytrinyx]

8 people have solved it in total. No comments other than a couple from Rikki (one of those might be a bug, looking into that). In three cases the author commented, but nobody has provided any feedback.

I don't think that is lack of interest, necessarily. I only comment on the first few exercises, because I only have so much time.

[kotp]

So I think there are not enough samples to know how this is working out yet.

I think if people are solving it that is an 'interest' indicator. I think only the presence of feedback indicates positive interest, but lack of feedback does not necessarily indicate lack of interest.

I think if it has a high "skip" occurrence then either it is not interesting, or too hard, or not quite understood.

I say we leave it in. I think we need it in a few more tracks. This will help determine what to do with it, and if more are needed.

[Cohen-Carlisle]

I think its a cool idea but quite a bit more complex than the usual exercism stuff.
There isn't much to go on in x-common, so one would need to check out the go implementation to the gist.
I'm also pretty sure that not all exercism users would find it enjoyable.
The idea in general feels better suited as a special track or sister project to exercism as in many ways its a reverse exercism.

tl;dr: I vote deprecate/remove counter from x-common.

[kytrinyx]

The idea in general feels better suited as a special track or sister project to exercism as in many ways its a reverse exercism.

This is what I've been thinking about lately. It's not that we can't have it in Exercism, it's that Exercism is already big and kind of hard to define. I think that a lot of interesting ideas would make great stand-alone projects and wonderful compliments to what Exercism is right now.

[kotp]

Ready to push the button on exercism/go#321 ?

[kytrinyx]

Yeah, ready. Thanks.