How to cranck unit tests under pressure, and not feeling dirty at the same time

It's called doing the right thing.
Well thats what I tell my self it is. When I read "Extreme programming Explained" by Kent Beck I read about a story of his about a project where he introduced extreme programming as a development process. The project went well until the deadline got really close and wished he could just throw XP from the window, hack the project together and completed the project in time to collect a big, fat, juicy bonus. He addmitted he panicked, and then calmed him self down when a colleague told him that nothing really changed, that they should plan for the last two weeks of the project as it were an ordinary iteration, and execute it as such with unit testing and everything.
Now I was in a pinch some time ago. Not something unusual, per self, it seems there is not enough time to ever do a project. The project was then involved was in development for some time, and the deadline of the clients patience got really closer as each week passed.
It was a good project, I've architected it and technically oversaw the development for much of its life time as I was in parallel involved in other enterprises. It got a stable architecture, which followed closely my plan, it got unit tests, inversion of control, mocking ,functional tests and a set of Selenium based acceptance tests.
I event wrote a set of QUnit (a javascript unit testing framework) test for the Javascript classes we used on the project.
The problem was that the we got a week left and still a lot of stuff to do if wanted to do it right, before the final client presentation. Like writing tests, logging code etc.
The pressure started to mount, just finish those damned screens everybody yelled (not really but my minds plays such beautiful tricks on me). Just get it done, write those pesky tests later.
The problem was I was feeling really good about the projects, the tests were written quickly and were really useful to ferret defects and I really didn't want to abandon all those three hundred plus tests to entropy and mocking disregard.
What I decided to do is to change my unit testing strategy:

• Test only logic heavy code. If a method has an if, switch or any other control structure I would test it in respect to the general expected behavior which could result from those control structures.
• Change focus from data to processes. I left trying to set replicas of real world data, and instead used generic values like "1" for ints and "Any" for strings. This left me with more time and didn't stress my mind to try to figure out real, representative , data sets.
• Tell your self is good to copy paste (for now). I had tests which were five to seven lines long each. They all had 30%-40% of the same code base. What I originally do I refactor out the common code in a private method and reduce my overall tests size. The downside of this it takes time do do it. Time which I really didn't have. So I copy pasted.
• In a object stack which covers a specific functionality (e.g. GetAllAccounts) do not retest the same functionality on each step, but instead focus really closely to the task of each object in the stack. For example I would focus really hard on querying and inserting data from the permanent storage in the Data Layer of the application, and focus on data transformation and repository logic in the middle tier of the application.

It kinda worked. I cranked a lot of more code this way and found a lot of defects. I wouldn't suggest it as a unit testing strategy for everyday situations but it kinda works when under pressure.