I would add to this by adding tests gradually during this time. If there is no understanding from management that this is needed, do it guerilla style and do it anyway, maybe at a smaller scale.
In my mind, unit tests is not what you want to start with with a messy legacy codebase. It takes a huge amount of effort testing lots of already working code. Add unit tests for any new code, but try and implement tests for the entire system, functional/integration tests are also easier to argue for in terms for direct benefit for the customer. Unit tests are more for the developer and is harder to argue for.
Adding tests makes it easier to confidently refactor the code later on.
Any practical suggestions on how to bootstrap testing (unit and/or UI) for an existing project that has never seen any? Or any recommended resources I could read up on?
Particular resources and guides are gonna depend heavily on language/frameworks/etc.
Start with areas that are the most valuable to the business. Not only does this more easily show the (business) value of testing, but it helps keep you from introducing a very visible and very bad looking regression. Anything dealing with money (especially billing) is probably a good indicator. Be warned, here be dragons.
That being said, don't verify your testing setup with business critical tests. Verify your setup (to yourself and other devs) with the quickest thing you can accomplish. The business critical ones are your (team's) short term goal.
Pick out the X most important logic paths (e.g. customer checkout or some subsection of that). Work on regression testing that over the next few months.
Make sure your tests are both automated and actually get run. The latter is more important than the former.
Ideally, your tests will prevent a nasty bug from going in and will immediately prove the business value of your testing efforts. This will establish the trust you need to continue testing and refactoring.
Hmm.. it's definitely tough to begin on a codebase with 0% coverage.
The first step is to stop the bleeding so begin adding unit tests for any new code you write and be sure to factor this effort in with your sprint estimations.
In parallel work top down with high level integration tests written against feature flows. E.g., As a user when I select this then I expect this. This doesn't mean you need to actually use BDD gherkin library for your test runner but at least frame the context of these in that regard since you don't care about the minute details of the underlying code, just the experience of the user story.
And lastly, don't just write tests to write tests, try to understand what is important to cover against because there is nothing worse than maintaining barely useful tests wired up to legacy data fixtures.
In my mind, unit tests is not what you want to start with with a messy legacy codebase. It takes a huge amount of effort testing lots of already working code. Add unit tests for any new code, but try and implement tests for the entire system, functional/integration tests are also easier to argue for in terms for direct benefit for the customer. Unit tests are more for the developer and is harder to argue for.
Adding tests makes it easier to confidently refactor the code later on.