Recently I have begun working part time for a small startup that has had a base version of their software already created by a company that used an overseas team. The codebase is large and in a language and framework that I have not worked in recently and uses features that I had not previously heard of.
On top of that their are large blocks of commented code, hardcoded values for things that need to be in a config file, and not one test.
As a professional software developer, when you are creating a large project for the company you work for, for a client or even for yourself, you absolutely should write test. Many people would even say you should write the tests first (TDD).
So what do you do when you inherit a large, legacy project that has zero tests?
Step One: Get a Build Working
Code is really difficult to test if the code doesn’t work or you don’t know how it should work. First you need to make sure you have a build that runs. If it doesn’t run, time to debug and get it running. It helps if you have someone who knows how it should be working so that even if it does not work properly, you can make it.
Step Two: Begin to Eat the Elephant
How do you eat an Elephant? One bite at a time.
Pick a small piece of the code and write a test for it. For the first test, try for a simple piece of code that does not rely on a bunch of things being mocked out (learned this the hard way).
Step Three: Take Another Bite
Repeat step 2 until you have reasonably good test coverage of the project. This does not necessarily mean 100% test coverage.
Bonus
If the code is particularly troublesome to get working, it is actually a good idea to write tests for sections of the code that do not work properly as you go through step 1. When something does not work, write a test that will pass when it does work and then fix the code.
Most importantly, remember to be a professional and write tests.