About Patterns - Singleton

The Singleton pattern allows a developer to provide access application wide to a class that has only one instance. This pattern can be useful when designing a class that represents a single resource (such as a print spool).

A few items to consider with the Singleton pattern:

• Control over how a client accesses a Singleton's instance is with the Singleton class
• The namespace isn't polluted with global variables when the Singleton pattern is used
• The number of instances is controlled in the Singleton class, so if at a later date it's determined more instances are required, it can be changed with less effort

More information including a sample implementation is available here.

About Patterns - Builder

The Builder pattern allows a developer to construct objects using a consistent construction process but yield different representations. This pattern is useful when the parts that make up an object should be different from the algorithm used to make the object and the construction process needs to produce different representations.

A few items to consider with the Builder pattern:

• The internal representation of the object built by the Builder is hidden
• The pattern encapsulates the construction and representation of the object built
• The pattern gives you more flexibility in the construction process

More information including a sample implementation is available here.

About Patterns - Memento

The Memento pattern allows you to restore a saved state of an object. This pattern is useful when obtaining the object's state would break encapsulation. There are three objects involved in the Memento pattern:

• Memento - the object that stores the internal state of the Originator
• Originator - the object that needs to be saved/restored
• Caretaker - the object that interacts with the Memento object but does not modify it

A few items to consider with the Memento pattern:

• Memento allows an Originator object to be restored without exposing the internals of the Originator
• The Originator is simplified internally by not having to handle the saving/restoring of state
• Mementos may grow costly as the size of the state contained in the Originator grows
• Care must be taken to restrict access to the Memento's state to only the Originator
• Depending on the size of the Memento, a Caretaker may grow large in terms of storage

More information including a sample implementation is available here.

JUnit - Fundamental Classes

Fundamental classes in JUnit include the test class, test suite, and test runner.

A test class must be a public class and have a zero-argument constructor. A test class may have one or more test methods which must be public, return void, take no arguments and have the @Test annotation. New instances of JUnit test classes are instantiated for each test method, so instance variables are not reusable.

Test classes use assert methods to determine whether or not expected values match the actual value. An example of an assert method would be assertSame. AssertSame takes three arguments (the first argument is the error message to present, then the expected value, and finally the actual value). Assert methods will throw AssertionError with a specified message if the assertion fails.

A test runner provides a way to specify how to run a test. The JUnitCore facade (which interfaces with test runners) provides a way to run tests and gather results.

A test suite is a collection of tests and/or other test suites. A class is defined with the RunWith and SuiteClasses annotations. A runner is specified with @RunWith(value=Runner.class) and the tests/suites are specified with @SuiteClasses(value={Test. class, Suite.class, ... } ).

Integration of suites with IDEs, Ant, and Maven is possible and recommended.

JUnit - An Introduction

JUnit is a testing framework written by Erich Gamma (one of the Gang of Four) and Kent Beck (creator of Extreme Programming and TDD). Integrating the JUnit framework into your project allows you to quickly develop unit tests without worrying about implementation details of the framework itself.

The JUnit team has the following design goals for the framework (From A Cook's Tour):

• Aid in the creation of useful test
• The tests must retain their value over time
• Test reuse should reduce the cost of writing tests

Setting up JUnit is easy. Download the distribution and add the JUnit jar to your classpath.

Classes no longer need to extend TestCase (as in JUnit 3) in JUnit 4. Test methods are indicated with the @Test annotation. Before and After methods are annotated with the @Before and @After annotations respectively.

JUnit Series

Over the next few weeks as I read JUnit in Action (2nd Edition, Amazon) I plan on summarizing what I learn in a series of blog posts. I will tag these blog posts with "junitinaction" and try to post them with content organized in logical chunks.

Blogging, Git and Old Code

I've decided to pick up blogging again, this time with only one blog as opposed to a few covering a variety of topics (I'll make use of tags instead).

Google Code just recently started offering Git as an option for their project hosting service. I plan on giving it a shot again.

There is a lot of code left over from both my undergraduate and graduate school days that I plan on uploading to various repositories very soon.