Yep.
Start small.
When planning, look for tests that will speed up your work now.
Don't care about overall coverage, only that what you are working on now is reasonably tested.
Always remember: if nobody has told you to test and what test to write then they are just a tool to help you.
Your tests can work as both a
- lab bench, keeping your code in place while you work on it
- fall protection
- a colleague that does pair programming with you, pointing out when you are about to forget something important
If some advice you get doesn't make sense and you can ignore it, do that after trying to understand what it should help for.
Michael Feathers book "Working Effectively with Legacy Code" might come in handy at some point.
Try writing tests to match requirements. Try writing tests, then refactoring to see if it doesn't break the test(still compiles)
Yep.
Start small.
When planning, look for tests that will speed up your work now.
Don't care about overall coverage, only that what you are working on now is reasonably tested.
Always remember: if nobody has told you to test and what test to write then they are just a tool to help you.
Your tests can work as both a
- lab bench, keeping your code in place while you work on it
- fall protection
- a colleague that does pair programming with you, pointing out when you are about to forget something important
If some advice you get doesn't make sense and you can ignore it, do that after trying to understand what it should help for.
Michael Feathers book "Working Effectively with Legacy Code" might come in handy at some point.