Books to read

Data Structure
Clean Code
Refactoring
Effective Java
Pragmatic Programmer
Thinking in Java

testing links

http://martinfowler.com/articles/mocksArentStubs.html


http://misko.hevery.com/code-reviewers-guide/


http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/

http://java.dzone.com/articles/static-methods-are-death-testa

http://www.codeproject.com/KB/cs/autp1.aspx#WorkOrder44

http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/

Lessons learned in testing

1. define for almost everything an interface. Everything, means
everything that the other classes probabaly need (factories, services,
and alike). You should use interfaces, otherwise you can't create
mocks.
2. Inject everything a class need (its dependencies), for exmaple
using its constructor.
3. during testing, you create mocks for these dependencies, and give
them to your class. This way you are sure you are testing you class in
isolation.

Remark 1: A mock is infact the means by which you break up this chain
of dependencies, so that you can test you class in isolation; and not
testing 10 other classes as you are "unit" testing your class. Imagine
the example of testing AssignmentFactory.

createAssignment() method. In
order to create an assignement, AssignementFactory needs a
MailingFactory needs an ImageFactory needs .... . By injecting the
factories in constructors and using interfaces, you have the
possibility to mock them and isolate for example AssignmentFactory
implementation from implementation of MailingFactory using
MailingFactoryMock.

Remark 2: As a rule of thum, your code most consist of classes who do
work, and classes that create the object graph by creating new
objects. Hence the classes who do work, should not contain "new"
statements.