You know what unit testing is. You believe in the benefits it will bring to you and your company. Yet, you're not unit testing. Why is that?
Here are the four biggest blockers and what you can do to obliterate them and start improving your codebase with unit tests.
1. No Buy-In From Management
Good news: this is easy to tackle. Some companies / managers may not want to give you time to write tests and clean up the code base because they want you working on new features and fixing bugs as fast as possible.
What you have to understand is that, as a professional software developer, you should feel an obligation to produce high-quality work. Even if your organization has a QA team, you need to be responsible for the quality of your output.
When management asks for time estimates, you need to add a margin for testing time. You don't need to tell them you're doing this. Think of testing as part of your work... as if coding and testing is an atomic operation. If you think some task will take 2 hours to code then give an estimate of 3 or 4 hours. It still falls within "as fast as possible" because testing is inherently part of the task.
And, if you are forced to justify your estimates, point out that you would typically perform manual testing while working on a feature / issue and that, by writing automated tests, you're actually saving time because all future testing of that feature / issue is performed by the computer rather than a human.
2. Static Friction
There's no testing framework currently in place and it's a pain to set up. Setting one up means you need to evaluate various options and pick something, incorporate it into the build, get it set up on the developer machines. You really just need to put your head down and power through this one. Once it's done, you'll feel so much better.
For a Microsoft stack use MSTEST or NUnit. I've had some pleasant experiences with NSubstitute recently for mocking/stubbing.
With Node.js I recommend Mocha + Expect (ignore Karma, Jasmine, Chai, Sinon, etc for now. Keep it simple until you need more).
3. The Code Is a Tangled Mess
Poorly written code is hard to test. Do you have massive class files, lots of static instances, leaky abstractions, poor separation of concerns, etc? Well, no wonder you aren't writing tests!
The solution here is to slowly start refactoring the code as you work on features and issues. I'll write about specific strategies in upcoming articles.
But even if you can't write unit tests because the code is too complex, you could find some success writing automated end-to-end tests (i.e. tests the system as a whole).
4. Unsure How To Write Tests
Sure, unit testing might seem daunting if you've never done it before. It takes a little practice, but it becomes easy very quickly.
Ideally your tests will exercise every code path. You should test sane data, boundary cases, and invalid data. When your code has dependencies, you should use fake/stub/mock objects in place of the real dependencies and then test every possible interaction between your code and the dependency.
For instance, if your code depends on opening a file, you should test what happens to your code when the file exists, doesn't exist, exists but access is denied, etc.
The topic of effective testing could fill a book.
What is stopping YOU from writing unit tests?