Do your team members actually agree that code reviews and unit testing are Good Things, just there is no time for these?
Or do they just try to reject the idea with this excuse?
In the first case, the solution is to Start Doing It Now. (OK, if you are in the last days before a major milestone, maybe you can wait until after - but no more.) We had that situation in a previous workplace of mine, where I was Quality Engineer, responsible for improving coding practices and overall quality. We kept deferring the start of code reviews till next week. One day I realized we have been doing this for a month or so, and probably will be continuing till the end of times unless I try something different. So I announced the first code review for that week. I told the guys "no problem if it will be imperfect, or if we don't exactly know what to do yet - we will just start doing it, see how it goes and improve things as we learn". It worked, at least until I left the company.
In the second case, you may need more education and open discussion with the team. Discuss code quality issues, ask them what they see as problems in the development process (or lack thereof) / in the code / testing etc. And brainstorm together about how to resolve these. The ultimate aim is not necessarily to do code reviews - they are just means, while the goal is to improve the development process and the quality of its output. It may well turn out that there are other, more painful issues which could be improved easier, bringing more benefit faster; then take these first. They can even be trivial changes in the environment or the process; all of these will improve team morale, build mutual trust and help the team bond.
The bottom line is, you can't force quality upon anyone - you can only remove the obstacles of creating quality. By enforcing strict rules and mandatory practices without prior team consensus, you may alienate the team and ultimately prevent the quality improvement you are aiming for. OTOH by open discussion and aiming for agreement on what the most pressing problems for the team are and how to improve the situation, you are more likely to get team support. This will make a crucial difference in keeping up the quality improvement drive in the long run.
It's rare, but sometimes it makes sense to have multiple test classes for a given class under test. Typically I would do this when different setups are required, and shared across a subset of the tests.
Best Answer
.aspx files, compared to corresponding .aspx.cs code-behind files) are expected to contain minimum programming code, i.e. large chunks of HTML with here and there the calls to variables, eventually with straightforward loops and conditions.
This means that you will rarely find unit tests for .aspx files, since there are no complicated algorithms or business rules there.
Since .aspx files can still introduce bugs, system testing seems a good choice. The way would be the same as the one you use to test whether your HTML code corresponds to the requirements.
Note: ASP.NET encourages to put too much programming code directly in .aspx files. In Microsoft's demos, you can even find SQL queries there. This is a terrible way to develop websites, and is misleading of what templates are.
For example, in Django templates in Python, things are much clearer, and you don't put your database logic in HTML templates. ASP.NET makes separation of concerns not obvious.
If you find yourself putting business logic or database logic in your HTML templates, or if you notice that many bugs are in your templates, consider introducing layers in your application, and keep only minimum code in templates.