Eric Amell's Tech Blog

In my last post I briefly described the process of TDD.  In that discussion I stated that a unit test will test in isolation; meaning that you don't want to test a unit's dependencies only the unit itself.  In the real world our code doesn't run in isolation, in the real world our code has dependencies.  I also stated that in a future post I would talk about test doubles, however before I can talk about that we need to discuss how we isolate our class from the world around it.  Of course we can't isolate it completely, a completely isolated class is generally useless, but we can decrease the dependencies.  This dependency on other classes is referred to as coupling and coupling is generally considered bad. An excellent way to reduce coupling is called inversion of control, which is also referred to as dependency injection.  Many people when they think of inversion of control think of frameworks such as Spring, JUICE, or Java EE.  Although these frameworks offer invers

This is the first in what I hope to be a series of blog posts on Test Driven Development (TDD) with Alfresco.  Before I can jump into the topic I want to make sure we are all on the same page with TDD.  I have heard a lot of definitions of TDD (primarily from interview candidates that haven't actually done TDD) and I know there is a lot of confusion as to what TDD is. Unit Testing Before I dive into TDD I want to talk a little bit about unit testing.  There are different types of testing, unit testing, integration testing, and system testing (there are others but all of them are out of scope of this blog except unit testing anyway :)).  Unit testing is the testing of a unit in isolation.  A unit of code in Java is generally a class.  The idea is that you are only testing the unit not the unit's dependencies (we will explore test doubles in a future post, for now just know there are ways to isolate your unit from its dependencies). With unit testing there are two sets of so