Code reviews are not a good substitute for unit tests; and it sounds like what you're describing your team as doing is more like linting, which you should use an automated tool for.

The purpose of unit tests is to catch regressions. They can also be an excellent tool to speed development in real time by using automated tests to confirm the code does what you want it to, instead of repeated click-through testing, which is often slower.

A habit of unit testing can (but doesn't always) encourage developers to adjust their mindset about writing code and to get into better habits. For instance, feature-oriented spaghetti code is hard to test. API-oriented code is easier to test, easier to maintain, and easier to extend. Developers thinking ahead about testing, or writing tests and application code in parallel, are also more likely to use patterns like dependency injection.

Code review is a terrible way to catch bugs, but it can be an excellent way to share knowledge. Both knowledge of the craft, shared from seniors to juniors; and domain knowledge / institutional memory of business practices, ins and outs of existing code, and the like. It's also a great opportunity to review design decisions and teach best practices in that regard.

You mention code review failing due to tight deadlines and everyone "just trying to finish their work". I see two potential issues here.

The first is the obvious one that it sounds like your team is a little overworked/understaffed. There are all sorts of reasons (that I'm not going to go into here) why it's bad for a team to have zero slack time. But not having time to step back and assess the outcome of the work is - as you've discovered - a major one.

The second issue is that it sounds as if your team might be a little short on cohesion. One way this might manifest is that they don't trust one another to give or receive feedback in an empathetic way, so they're afraid of requesting or providing in-depth feedback. Another is that they don't feel a personal obligation to one another to make time to provide the sort of in-depth feedback that anyone should desire if they want to continue improving at their craft (and which is one of the primary benefits of working on a team instead of solo). A useful code review on a 1000-line changeset doesn't have to take more than 15 minutes.

I don't know exactly what sorts of code quality issues your organization has been encountering, but I can add an anecdote.

My team has introduced both code review and unit testing in the past 18 months.

Code review was adopted hesitantly at first, but then with enthusiasm. I wouldn't say it's had much impact on typical code quality or caught many bugs, but it has improved communication and caught a few architectural mistakes that might have been painful to deal with if they'd made it to production.

Unit testing didn't really catch on until we implemented continuous integration to make sure the tests ran - and passed - after every change. In fact, getting the first green build took a week of fixing tests that hadn't been run or updated in months. Since then we've also added a Slack bot to shame anyone who breaks the trunk build, and our test suite has expanded from roughly 25 tests to about 600. And our tests have uncovered or prevented more regressions than I can count.

Some team members have taken to unit testing with more enthusiasm than others, despite a directive that all new development must have test coverage. One team member uses it proactively, even to reproduce bugs before fixing them; another uses it only for green-field development; another I have to pull teeth to convince to add tests (even though he concedes that they're enormously useful for catching regressions and verifying that dependency upgrades are safe, and even though his design decisions have leveled multiple levels up since we started testing); another built an entire back-end feature by running his code only in the test suite because he didn't have a UI to run it in and the setup was too complex to run comfortably in the REPL.