Important rules when writing tests for your application

Today I want to share some of the most important rules I follow when writing tests for an application. These are some rules I found useful to follow so that tests remain a part of my job which improves on the long term the quality of the code I deliver and makes my life easier. In my opinion same rules apply whether you are doing test driven development or just writing tests after you completed a feature, of course that its preferable to do test driven development as it brings more value to your code quality and your application.

1. Tests should be small! What does this mean? Well tests should be easy to read, easy to understand and the test should not have hundreds of lines of code. When writing tests you should follow the same rules as you do when writing clean code. Often after several days, weeks, months or even a year you will need to update a feature, which means the tests should be updated, but how will you update the test if it was written such that you cant understand it?
2. As you might know there are functional tests and unit tests, the purpose of a test should be to verify that a single functionality works in case of functional tests and in case of unit tests the purpose should be to verify that a method has the expected behavior which can be to return a result or to modify the state of an object.
3. Tests should be independent from each other! One or more tests should not fail because one other test fails. If a test failed it should be because the feature or the method has some issues in its implementation. Also the order of running the tests should not matter, running the tests should output the same result. An example of dependent tests is when first test creates a user and tests if it was saved in the database and then the second tests uses that saved user from database to test the login functionality.
4. Tests should be independent of the existing data in your database. What I mean by that is that as long as the database schema is the same every time you run your tests the same output should appear. For example you cant suppose when you test a login feature that the same username and password will exist in your database. In your test you should always either use mock objects or insert a user in the database, test login and then remove the user from database. Of course that most of the time its preferable to use mock objects instead of using the database. Same applies for resources used by the application, resources like log files or just simple files in which you store information. Usually when you have a really small application its not worth to use a database and you can use a text file to store information, so when writing a test make sure that in that test you also create a mock text file and delete it after your asserts finished.
5. Its very important how fast your tests are. It's a waste of time to wait dozens of minutes to run all tests for your application each time you finished a feature, sometimes you will need to run tests after each couple of minutes of writing code. I have seen very big applications(put in production but continuously improved during several years) for which running tests takes even few hours on a a high performance machine. In general to make your tests faster you can decouple your application from the database and use mock objects in your tests and you can not test the GUI of an application each time but that would mean that the "view" part of your application has very small amount of logic, which is a good practice. See how testing an application helps us to write better code? 

There a lot of other rules I might have missed, but consider this just a starting point!