Compile error Easy Mock

Easy Mock is a mocking library for Java which can help you to test your code isolated from some other components.

If you ever get the next compile error:
"expected (java.lang.void) in easymock cannot be applied to (void)"
It may be a result of you trying to call EasyMock.expect(mock.methodWhichReturnsVoid()), instead of doing that you should use expectLastCall method, you can use it like:
mock.methodWhichReturnsVoid(); 
EasyMock.expectLastCall();

I posted this tip because it took me several minutes to figure out what I was doing wrong, by the way, I was really tired!

Robert Rusu

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!

Maintainability of the code by constant refactoring and unit testing

How often, as a programmer, you delivered new features in the beginning of the project so fast that clients could not believe it, but later, when the project got bigger, the number of lines of code grew and the number of features became larger, you started delivering features very slow? Often that was because the bad architecture of the application but mostly it was because the ugly code you were writing!

What did you do next? Well I suppose that you tried to refactor the code but you might have not succeeded because you were scared that you would introduce bugs. But keeping the code as it is wouldnt be a solution because as you know code rots as time passes, the code becomes uglier and uglier with every new feature or small change if you do not clean it. The solution would be to have unit tests, right?
If there would be tests and you would not be scared to do the refactoring of the code. But then you would need to convince your clients to spend money on refactoring working code. Most of them will not understand that refactoring will mean less money and less time spent on the long run.

I think that the best solution to this situation would be that whenever you work on a new feature or change an existing one because requirements change you should always leave the code cleaner that it was before. When see a piece of ugly written code apply one of the appropriate refactoring pattern without being scared that you might break the behaviour of the application because you are backed up by your unit tests.

Following this rule "leaving code cleaner that it was before you started working on it" and having unit tests will help you have a constant delivering time of new features, no delays because of the complexity of existing code, no bugs introduced by small changes and it will make you happier while working because you know you are delivering high quality software.