In a regular application, you would not have two tests, you would need tens or hundreds of them. Could you imagine anyone checking all of these properly at every single release? That would be insane.
Automated-testing (the only sane way)
An automated test is the same as a manual test except that it’s run by a computer. An automated test is some code that usually does three things: it sets the current data, performs an action as a fake user and checks the expected result.
Automated tests need to be written once only. With these, developers can check in a few seconds that the login page works as planned. If a few months later the website is entirely re-skinned, the first test above would warn developers if someone forgot to include the error messages on that login page.
With tests, developers can improve their code without worrying about breaking anything. As they can freely improve the code, they can update names, break it down, re-organise it, etc.
Tests are also the only realistic way to prevent a bug from reoccurring. When an issue is found, developers can add a test to reproduce the issue and fix it. With that test in place, you can be sure that the same bug will never happen again (without being noticed first by the developers). There is no other way to be sure. You cannot expect someone to retest the same patterns at every single release manually.
Basically, testing is the tool that allows the virtuous circle mentioned above to happen.
They are plenty of ways to limit bugs:
- picking and consistently using various coding standards
- breaking down the code into smaller blocks
- regularly improving and reorganising the code (technically called refactoring)
- code reviews
- keeping the user interface simple
- tracking bugs
While all of these techniques (or best-practices) are great; most of them are made easier with proper automated-tests and some of them are almost impossible without tests.