[exercises/bob] Mention linebreak handling

[oleks]

No description provided.

[IsaacG]

1. This file is copied/synced from the upstream problem spec and should not be charged from that. An instructions.append can be used if needed.
2. The tests are the authoritative source of the requirements. The instructions aren't always entirely complete, and that's fine; we rely on the test driven approach.

[oleks]

1. This file is copied/synced from the upstream problem spec and should not be charged from that. An instructions.append can be used if needed.

I see.

2. The tests are the authoritative source of the requirements. The instructions aren't always entirely complete, and that's fine; we rely on the test driven approach.

But then you tend to "game" the test suite rather than show ability to implement what is asked of you in human language. That's fine, but just mentioning this shortcoming.

[oleks]

2. The tests are the authoritative source of the requirements. The instructions aren't always entirely complete, and that's fine; we rely on the test driven approach.

But then you tend to "game" the test suite rather than show ability to implement what is asked of you in human language. That's fine, but just mentioning this shortcoming.

Furthermore, an improperly stated description can lead you astray until you have read/run the tests. In this particular case, I first implemented a solution which was correct by the description, but wrong by the tests: I let bob respond to each line in the input (which honestly, seems just as sensible). I don't really care which way around it is, but why make the implementer waste their time?

[IsaacG]

It is recommended you always run the tests first. Exercism explicitly takes a TDD approach and explicitly relies on the tests to drive the requirements.

If a user wants to game the tests, changing the description slightly will not change anything.