3 ms·

Jumping straight from cowboy to TDD is a big change. I suggest a much simpler rule to get started: whenever something breaks in production, add a test that ensu

by lacker 11y ago

Jumping straight from cowboy to TDD is a big change. I suggest a much simpler rule to get started: whenever something breaks in production, add a test that ensures it won't break again. That's all! Taking a small bite of testing ensures that you actually see the value of unit testing without going nuts and totally changing your development process. Once you have that much going, you can do more testing.

davismwfl 11y ago
I totally agree. Having been in the same shoes this is the best route usually. I am all for setting up CI and have the ability for a failed test to fail the build etc, but start simple. Pick a framework you can all agree seems reasonable and write tests for things that break. Then as you add new code write tests there too. As you do this you will quickly wind up with 10 then 30 etc and the tests will just start building up and before you know it you have a serious test suite and your mindset will have shifted. Personally I do not start a new project with TDD. I know I will likely get smacked for admitting it. But to me get the basic app whipped into a useable product then introduce more discipline via testing this way. That way yes you pay some for it, but you have clients or a slid demo etc. Writing a great app with tons of tests that misses the mark doesn't benefit anyone. Faster iteration early on is more important. Of course I caveat this some, if you are adding a component to an already built system or in an enterprise I'd likely build tests first.
ZainRiz 11y ago
Exactly. As you try to write tests for things that break you may find that it's actually really hard to write tests. You need to initialize a database, or your code depends on X, Y, Z, and they all need to be setup. This is an opportunity for refactoring. Try to refactor just the code that's affected by the bug in a way that lets you inject any dependencies that it had. You can then inject Mock, Fakes, etc, and validate that the code your refactored out works as expected. You've now added tests and refactored your code to be more maintainable. A 2 for 1 punch.

by lacker 11y ago

davismwfl 11y ago

I totally agree. Having been in the same shoes this is the best route usually. I am all for setting up CI and have the ability for a failed test to fail the build etc, but start simple. Pick a framework you can all agree seems reasonable and write tests for things that break. Then as you add new code write tests there too. As you do this you will quickly wind up with 10 then 30 etc and the tests will just start building up and before you know it you have a serious test suite and your mindset will have shifted. Personally I do not start a new project with TDD. I know I will likely get smacked for admitting it. But to me get the basic app whipped into a useable product then introduce more discipline via testing this way. That way yes you pay some for it, but you have clients or a slid demo etc. Writing a great app with tons of tests that misses the mark doesn't benefit anyone. Faster iteration early on is more important. Of course I caveat this some, if you are adding a component to an already built system or in an enterprise I'd likely build tests first.

ZainRiz 11y ago

Exactly. As you try to write tests for things that break you may find that it's actually really hard to write tests. You need to initialize a database, or your code depends on X, Y, Z, and they all need to be setup. This is an opportunity for refactoring. Try to refactor just the code that's affected by the bug in a way that lets you inject any dependencies that it had. You can then inject Mock, Fakes, etc, and validate that the code your refactored out works as expected. You've now added tests and refactored your code to be more maintainable. A 2 for 1 punch.