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.
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.