Your comment is exactly what I try to get across in the book but it's not always easy.
If you cant decide how you want something to look (as that's not always easy) just take a punt on something. Make sure it's a small decision and make something useful. Sure you might have to change it, but at least you'll be basing that on some real feedback.
Hi, thank you for writing the book! Great introduction to Go.
One thing I was uncomfortable with about TDD is the step to "just write enough to make the test pass". The danger seems to be when you have to walk away from some code and you or whoever picks up your code doesn't know what you were up to.
In a simple app and a few tests you could probably tell, but the larger an application gets, the less you can put effort into finding out "this test works because the application works how it should" or "this test works because someone wrote just enough code and hardcoded some value somewhere in order to make the test pass".
It seems "safer" to write tests that are going to stay broken until every little corner of everything works properly, even though this is less iterative.
As mentioned above I have little TDD experience, so maybe I'm missing something.
The point of "just writing enough to make the test pass" is to get you to the point where you have working software (proven by the test, even if the code is "bad")
This is the _only_ point where you can safely refactor, if your tests are failing how do you know you haven't broken something? So long as you keep things "green" you know you're ok
> The danger seems to be when you have to walk away from some code and you or whoever picks up your code doesn't know what you were up to.
Just don't do this. You're not "done" with the TDD cycle until you make it pass and have refactored.
I reflect this in my git usage too, roughly it goes
- Write a test
-> Make it pass
-> git commit -am "made it do something"
-> refactor
-> run tests (if i get in a mess, revert back to safety and try again)
-> git add .
-> git commit --amend --no-edit
> It seems "safer" to write tests that are going to stay broken until every little corner of everything works properly, even though this is less iterative.
The problem with this is how do you safely refactor when you have potentially dozens of tests failing?
A big point of this approach is it makes refactoring a continuous process and makes it easier because you have tests proving you haven't accidentally changed behaviour.
