DaedTech

Stories about Software

By

JUnit Revisited

Just as a warning, in this short post, I’m going to be writing unit tests that verify that primitives in Java do what they should and basically that gravity is still turned on. The reason for that is that I’d like to showcase some new Java unit testing goodies I’ve recently discovered since coming back into the Java fold a little here and there lately. I firmly believe that the more conversationally readable the contents of unit tests are, the more effective they will be at defining functional and internal requirements as well as showcasing the behavior of the system.

@Test
public void two_ints_are_equal() {
	int x = 4;
	int y = 4;
	assertThat(x, is(y));
}

Coming from the .NET world and using MSTest, I’m used to semantics of Assert.AreEqual<int>(x, y) where, by convention, the “control” or expected value goes on the left and the actual value goes on the right. This is a compelling alternative in that it reads like a sentence, which is always good. The MSTest version reads “Are equal x and y” whereas this reads “x is y.” The less it reads like Yoda is talking, the better. So what enables this goodness?

import static org.junit.Assert.assertThat;
import static org.hamcrest.CoreMatchers.is;
import static org.hamcrest.CoreMatchers.not;
import static org.junit.matchers.JUnitMatchers.*;

The first import gives you assertThat(), obviously. assertThat() as shown above takes two parameters (there is an overload that takes a string as an additional parameter to let you specify a failure message): a generic type for the first parameter, and a “matcher” for the second parameter. Matchers perform evaluations on types and can be chained together in fluent fashion to allow construction of sentences that flow. For instance, you can chain the is() matcher and the not() matcher to get the following test:

@Test
public void two_ints_are_not_equal() {
	int x = 4;
	int y = 5;
	assertThat(x, is(not(y)));
}

This really just scratches the surface and there are lots of additional matchers from hamcrest as well. You can even extend the functionality by defining your own matchers to cater to the ubiquitous language of the domain that you’re using. This just barely scratches the surface, but if you’re a java developer and haven’t given these a look, I’d suggest doing so. If you’re a .NET developer, it’s worth taking a peek at what’s going on elsewhere and perhaps defining your own such constructs if you’re feeling ambitious or looking for existing ones. In fact, if you know of good ones, please post ’em — I always like seeing what’s out there.

By

JUnit for C# Developers 8 – Obeying Demeter and Going Beyond the Tests

Last time in this series, I pulled an “Empire Strikes Back” and ended on a bit of a down note. This time around, I’d like to explore how I’ve alleviated my Law of Demeter problems, and about how fixing a code smell in my tests pushed me into a better design.

Up until now, I’ve been blogging as I go, but this one is all in the past tense — the work is done as I type this. I set out tonight with only one goal, get rid of my LOD violations, and this is where it took me.

Rethinking my Class

Recall that last time, I was passing in a database object, querying that for a collection, querying that for a cursor, and then querying the cursor for my actual database objects that I parsed and returned from the service. After a bit of trial and error and research, I decided that my service class needed to encapsulate the collection since, as best as I can tell from whatever Eclipse’s version of Intellisense is called, cursors are forward only and then you need to get another one. So, if I don’t pass in the collection at least, my service method will only work once. Fine – not thrilled about the collection.cursor.objects thing, but it’s at least pulling one LOD violation out.

I now have a handful of tests that look like this:

@Test
public void returns_room_model_with_roomName_from_database_room_key() {
	
	String myRoomName = "Rumpus Room.  Yeah, that's right.  I said Rumpus Room.";
	
	DBObject myMockDatabaseObject = mock(DBObject.class);
	Mockito.when(myMockDatabaseObject.get(RoomServiceMongoImpl.ROOM_NAME_KEY)).thenReturn(myRoomName);
	
	DBCursor myMockCursor = mock(DBCursor.class);
	Mockito.when(myMockCursor.next()).thenReturn(myMockDatabaseObject).thenReturn(myMockDatabaseObject).thenReturn(null);
	Mockito.when(myMockCursor.hasNext()).thenReturn(true).thenReturn(true).thenReturn(false);
			
	DBCollection myMockCollection = PowerMockito.mock(DBCollection.class);
	Mockito.when(myMockCollection.find()).thenReturn(myMockCursor);
	
	RoomServiceMongoImpl myService = BuildTarget(myMockCollection);
	
	assertEquals(myRoomName, myService.getAllRooms().toArray(new Room[2])[0].getRoomName());
}

and my class became:

public class RoomServiceMongoImpl implements RoomService {

	public static final String ROOM_CODE_KEY = "room_code";

	public static final String ROOM_NAME_KEY = "room";
	
	private DBCollection _collection;
	
	public RoomServiceMongoImpl(DBCollection collection) {
		_collection = collection;
	}

	@Override
	public Collection<Room> getAllRooms() {
		Collection<Room> myRooms = new ArrayList<Room>();
		
		DBCursor myCursor = _collection.find();
		while(myCursor != null && myCursor.hasNext()) {
			RoomModel myModel = buildRoomModel(myCursor.next());
			if(myModel != null)
				myRooms.add(myModel);
		}
		
		return myRooms;
	}
	
	private RoomModel buildRoomModel(DBObject roomObject) {
		Object myRoomName = roomObject.get(ROOM_NAME_KEY);
		char myRoomCode = getRoomCode(roomObject.get(ROOM_CODE_KEY));
		
		if(myRoomName != null) {
			return new RoomModel(myRoomName.toString(), null, myRoomCode);
		}
		return null;
	}

	private char getRoomCode(Object myRoomCode) {
		return myRoomCode != null && myRoomCode.toString() != null && myRoomCode.toString().length() > 0 ?
				myRoomCode.toString().charAt(0) : 0;
	}
}

A lot cleaner and more manageable following some good TDD if I do say so myself (though I may be whiffing on some finer points of the language as I’m still rusty from 2 years of mostly uninterrupted C#). I’m still not thrilled about the heavy test setup overhead, but I’ve made incremental progress.

Now, where things got interesting is in wiring this up through Spring and MongoDB. The class works in test, but I need now to figure out how to use my spring-servlet.xml to get an instance of the collection injected into my class’s constructor. I wanted to do this (1) without defining any additional code and (2) without resotring to static implementations or singletons. For (1) I’d rather leave the DB setup stuff in XML as much as possible and for (2) I try to avoid static at all costs unless there’s some compelling argument that doesn’t lean prominently on a premise of “it’s more convenient”. Static is about as flexible as a diamond.

So, here is what I did:

<!-- This is the "Mongo" object where you specify connection credentials -->
    <bean id ="mongo" class="com.mongodb.Mongo">
    	<constructor-arg index="0" type="java.lang.String" value="192.168.2.191"/>
    </bean>
    
    <!--  This is the database returned from the mongo object (the daedalus) database -->
    <bean id="mongoDatabase" factory-bean="mongo" factory-method="getDB">
    	<constructor-arg index="0" value="daedalus"/>
    </bean>
    
    <!-- This is the "house" collection, which is a collection of rooms  -->
    <bean id="mongoHouseCollection" factory-bean="mongoDatabase" factory-method="getCollection">
    	<constructor-arg index="0" value="house"/>
    </bean>

I discovered that I can use factory-bean and factory-method attributes to invoke instance methods on beans that I’d created, turning their return values into other beans. I also learned that “constructor-arg” is rather unfortunately named in that it actually just translates to “arguments to the method in question”. So, in the case of the mongoDatabase bean, I’m getting it from my mongo object’s getDB() method with a string parameter of “daeadlus”. On the whole, the beans above translate to new Mongo(“192.168.2.191″).getDB(“daedalus”).getCollection(“house”) being stored in the “mongoHouseCollection” bean, which I injected into my service. When I wired and fired it, it worked perfectly the first time.

So, this post has been a little thin on actual information about JUnit (really just the denouement to my last post), but there is a nugget in here for spring wireup, and, I think the most important lesson for me is that the design benefits to TDD go beyond just code. By taking my test smell seriously, I wound up with a design where I completely factored the database setup garbage out of my code, which is clearly a good thing. Now, I’ve been around the block enough times that this would have happened regardless, but it was interesting to note that making a testability/clean-code decision and sticking to my guns teased out a macroscopic design improvement.

By

JUnit for C# Developers 7 – Law of Demeter and Temporal Mocking

Last time in this series, I posted about a good reminder of a couple of principles of good object oriented design (respecting the Law of Demeter and avoiding static method invocations as much as possible). Today, I’m going to double back on this consciously a bit to explore some more possibilities in JUnit. Don’t worry – I will fix the design in subsequent posts.

Goals

Today, I’d like to accomplish the following:

  1. Have a mock change with each invocation
  2. Mock a low of demeter violation in as little code as possible

To the Code!

If you’ve followed my last few posts, you’ve noticed that I setup MongoDB. So, logically, the next step is connecting to it with my application, and the next step after that is mocking this connection so that I can unit test the logic (well, since I’m following TDD, technically the mocking comes first). Through trial and error in a throw-away piece of code, I discovered that I could access my database as so:

public class HouseServiceMongoImpl implements HouseService {

	private Mongo _mongoConnection;
	
	private DB _database;
	
	public HouseServiceMongoImpl() {
		try {
			_mongoConnection = new Mongo( "192.168.2.191" , 27017 );
			_database = _mongoConnection.getDB("daedalus");
		} catch (UnknownHostException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (MongoException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}

	@Override
	public House getHouse() {
		DBCollection myCollection = _database.getCollection("house");
		DBCursor myCursor = myCollection.find();
				
		List<String> myStrings = new ArrayList<String>();
		
		while(myCursor.hasNext()) {
			myStrings.add(myCursor.next().get("room").toString());
		}
		return new HouseModel(myStrings);
	}
	
}

Notice here that I’ve inlined instantiation of my dependencies in a form bad for testability. I won’t repeat this mistake in the actual, TDD version. This was just for me to see what actually worked and provide some context for what I’m trying to do. In my real class, RoomServiceMongoImpl, I’m going to be returning a collection of room objects, rather than a house object. So, without further ado, on to the TDD. To get things started, I wrote the following test:

public class RoomServiceMongoImplTest {

	private static RoomServiceMongoImpl BuildTarget(DB database) {
		
		return new RoomServiceMongoImpl(database);
		
	}
		
	public static class getAllRooms {
		
		/*
		 * If the driver gives us back nothing for this collection, return an empty collection to clients
		 */
		@Test
		public void returns_empty_list_when_database_get_collection_returns_null_for_house() {
			
			DB myMockDatabase = mock(DB.class);
			Mockito.when(myMockDatabase.getCollection(Mockito.matches("house"))).thenReturn(null);
			RoomServiceMongoImpl myService = BuildTarget(myMockDatabase);
			
			assertEquals(0, myService.getAllRooms().size());
		}
	}
}

This allowed me to create the room service and inject into it the DB object, since as far as I can tell, I gain nothing by injecting the Mongo object. So, my first test is that we get back a null object in the form of an empty list when the MongoDB collection requested is empty. This makes sense, as it means we have no house (and thus no rooms).

When doing TDD, I’ve gotten in the habit of teasing out any control flow by varying up the return value of the method. So, the first test returns an empty collection. The next test will return count of one. The next will return a bunch. The one after that may go back to zero but in a different set of circumstances. This sort of progression allows me to make progress while covering all my bases. So, here, I’m going to do the setup necessary for a list with a single item to be returned.

But… as it turns out, this isn’t trivial. From my database, I’m getting a collection, which I’m asking for a database cursor, which I’m asking in a loop for an object called “next”, which I’m then asking for my actual room’s string value (its name). This has the Law-of-Demeter violating form db.getCollection().find().next().get(string). Ugh. That’s a lot of mocking, and creating mocks this way is the smell of LOD violations in your code. But, let’s suck it up for now and create the mocks:

@Test
public void returns_list_with_one_item_when_db_returns_matching_cursor() {

	DBObject myMockDatabaseObject = mock(DBObject.class);
	Mockito.when(myMockDatabaseObject.get(Mockito.anyString())).thenReturn("asdf");
	
	DBCursor myMockCursor = mock(DBCursor.class);
	Mockito.when(myMockCursor.next()).thenReturn(myMockDatabaseObject);
			
	DBCollection myMockCollection = PowerMockito.mock(DBCollection.class);
	Mockito.when(myMockCollection.find()).thenReturn(myMockCursor);
	
	DB myMockDatabase = mock(DB.class);
	Mockito.when(myMockDatabase.getCollection(Mockito.matches("house"))).thenReturn(myMockCollection);
	
	RoomServiceMongoImpl myService = BuildTarget(myMockDatabase);
	
	assertEquals(1, myService.getAllRooms().size());
}

This was particularly annoying to write since it cost me a good bit of frustration trying to figure out why I was getting cryptic error messages about the wrong return type. Turns out it was because the collection.find() method is final, requiring me to use PowerMockito (this stack overflow post ended my suffering and I voted the poster up both for the question and his self-answer as my way of saying thanks). But, I was done, and the following class made the test pass:

public class RoomServiceMongoImpl implements RoomService {

	/**
	 * This is the MongoDB database object we'll use for our queries
	 */
	private DB _database;
	
	/**
	 * Dependency injected constructor
	 * @param database
	 */
	public RoomServiceMongoImpl(DB database) {
		_database = database;
	}

	@Override
	public Collection<Room> getAllRooms() {
		Collection<Room> myRooms = new ArrayList<Room>();
		
		if(_database.getCollection("house") != null && _database.getCollection("house").find().next().get("bkag") != null) {
			myRooms.add(new RoomModel("blah", null, 'A'));
		}
		return myRooms;
	}
}

Hideous, with all of those LOD violations, but functional. So now, the next step is to factor the code toward something less obtuse with my TDD, and an excellent way to do this is the case of two strings in the database. But, in order to make that happen, the cursor mock’s next() method has to first return a DB object and then return null. It just so happens that this is goal number one, and it can be achieved as follows:

DBCursor myMockCursor = mock(DBCursor.class);
Mockito.when(myMockCursor.next()).thenReturn(myMockDatabaseObject).thenReturn(myMockDatabaseObject).thenReturn(null);
Mockito.when(myMockCursor.hasNext()).thenReturn(true).thenReturn(true).thenReturn(false);

Note the chained returns calls. I took what I had in the previous test and turned it into this code, and then amended the expected size of the collection returned to be 2 using hasNext() and next(). I also had to go back and add similar code to the previous test for completeness sake. With this in place, the CUT getAllRooms() method became:

@Override
public Collection<Room> getAllRooms() {
	Collection<Room> myRooms = new ArrayList<Room>();
	DBCollection myCollection = _database.getCollection("house");
	if(myCollection != null) {
		DBCursor myCursor = myCollection.find();
		if(myCursor != null) {
			while(myCursor.hasNext()) {
				myRooms.add(new RoomModel(myCursor.next().get("asdf").toString(), null, 'A'));
			}
		}
	}
	return myRooms;
}

Man, that’s ugly. But, it works, and that’s what matters. We’re going to pretty this up and make it more robust later during the “refactor” cycles of red-green-refactor. So, on to goal number two, which is to compact the mock setup code somewhat. Granted, the pain of this setup indicates a design smell and there is a good argument that we should not deoderize these test smells. But, given that this is partially an endeavor for me to learn and blog about the mocking tools available with JUnit, I’m going to make an exception, with a promise to myself that I will pay off this loan of technical debt later by doing what I can to cut down on the database boilerplate I don’t need in this class. I came up with this:

@Test
public void returns_list_with_one_item_when_db_returns_matching_cursor() {

	DBObject myMockDatabaseObject = mock(DBObject.class);
	Mockito.when(myMockDatabaseObject.get(Mockito.anyString())).thenReturn("asdf");
			
	DB myMockDatabase = mock(DB.class);
	
	Mockito.when(myMockDatabase.getCollection(Mockito.matches("house"))).thenReturn(PowerMockito.mock(DBCollection.class));
	Mockito.when(myMockDatabase.getCollection(Mockito.matches("house")).find()).thenReturn(mock(DBCursor.class));
	Mockito.when(myMockDatabase.getCollection(Mockito.matches("house")).find().next()).thenReturn(myMockDatabaseObject).thenReturn(null);
	Mockito.when(myMockDatabase.getCollection(Mockito.matches("house")).find().hasNext()).thenReturn(true).thenReturn(false);
	
	RoomServiceMongoImpl myService = BuildTarget(myMockDatabase);
	
	assertEquals(1, myService.getAllRooms().size());
}

But, it throws a null reference exception on the first find() setup (second Mockito.when() line) and it doesn’t really save any code anyway, so I see no advantage to going this route. My instincts were against it anyway, and since it doesn’t work as fluidly as I hoped it might (I feel like I could probably get this fluent-style to work with enough persistence) and doesn’t save us code, forget it. Nothing ventured, nothing gained. I’ll have to be satisfied that this fluent-chaining appears possible, but might be a stone better left un-turned in favor of going back and cleaning up my code by eliminating LOD violations and generally seeking not to have them.

These posts are getting a little fewer and further between now as I’m less frequently blazing new trails in my work. I will probably check back in on this line of posts when I factor the design of this a bit, as kind of a MongoDB/JUnit fusion post.

By

JUnit for C# Developers 6 – Cart Before the Horse

In this post, I’d like to point out something I learned while working following yesterday’s post. In my haste to find the JUnit equivalent of MS Moles, I didn’t stop to think about what I was doing.

So, as I expanded on yesterday’s effort, I realized that my mocking of Runtime.getRuntime() didn’t seem to be working properly. As I set about trying to fix this, something dawned on me. Runtime.getRuntime() returns a Runtime object, and it’s that object’s exec(string) method that I’m interested in. So, in the code that I was trying to test, I was engaging in a double whammy of a Law of Demeter violation and inlining a static dependency.

I believe I was distracted, as I mentioned, by my desire to find C# equivalents in Java and by the general newness of what I was doing. But, this is a “teachable moment” for me. It’s easy to slip into bad habits when things are unfamiliar. It’s also easy to justify doing so. When I realized what I was doing, my first thought was “well, give yourself a break, Erik — just go with it this way until you’re more comfortable.” I then shook off that silly thought and resolved to do things right.

It’s easy to follow good design principles when you’re following a tutorial or being taught. But, it’s imperative to do it all the time so that it becomes a reflex. This includes when you’re tired late at night and just wanting to turn off your downstairs light without going downstairs (my situation now). It includes when you’re behind schedule and under the gun on a project. It includes when people are giving you a hard time. It’s always. If you practice doing it right — make it rote to do it right — then that’s what you’ll do by default.

So, humbled, here is my updated code:

Tests


@RunWith(Enclosed.class)
public class LightManipulationServiceHeyuImplTest {

	private static LightManipulationServiceHeyuImpl BuildTarget() {
		return BuildTarget(Mockito.mock(Runtime.class));
	}
	
	private static LightManipulationServiceHeyuImpl BuildTarget(Runtime runtime) {
		return new LightManipulationServiceHeyuImpl(runtime);
	}
	
	public static class constructor {
		
		/**
		 * This class makes no sense without a runtime, so don't let that happen
		 */
		@Test(expected=IllegalArgumentException.class)
		public void throws_IllegalArgumentException_when_runtime_is_null() {
			new LightManipulationServiceHeyuImpl(null);
		}
	}
	
	public static class toggleLight {
		
		/**
		 * Make sure the service is invoking the runtime's exec() to invoke heyu
		 * @throws IOException
		 */
		@Test
		public void invokes_getRuntimes_exec() throws IOException {
			
			Runtime myMock = PowerMockito.mock(Runtime.class);
			Process myProcessMock = PowerMockito.mock(Process.class);
            Mockito.when(myMock.exec(Mockito.anyString())).thenReturn(myProcessMock);
            
			LightManipulationServiceHeyuImpl myService = BuildTarget(myMock);
			myService.toggleLight(new Light("asdf", "Fdsa"), true);
			
			Mockito.verify(myMock).exec(Mockito.anyString());
		}
		
		/**
		 * If the exec works fine, then return true for successful command
		 * @throws IOException
		 */
		@Test
		public void returns_true_when_exec_does_not_throw() throws IOException {
			Runtime myMock = PowerMockito.mock(Runtime.class);
			Process myProcessMock = PowerMockito.mock(Process.class);
            Mockito.when(myMock.exec(Mockito.anyString())).thenReturn(myProcessMock);
            
			LightManipulationServiceHeyuImpl myService = BuildTarget(myMock);
			assertEquals(true, myService.toggleLight(new Light("asdf", "Fdsa"), true));
		}
		
		/**
		 * If the runtime's exec throws an exception, then this was not a successful op
		 * @throws IOException 
		 */
		@Test
		public void returns_false_When_exec_throws_exception() throws IOException {
			Runtime myMock = PowerMockito.mock(Runtime.class);
            Mockito.when(myMock.exec(Mockito.anyString())).thenThrow(new IOException());
            
			LightManipulationServiceHeyuImpl myService = BuildTarget(myMock);
			assertEquals(false, myService.toggleLight(new Light("asdf", "Fdsa"), true));
		}
		
		/**
		 * If we get a null process back, something went wrong
		 * @throws IOException
		 */
		@Test
		public void returns_false_when_exec_returns_null() throws IOException {
			Runtime myMock = PowerMockito.mock(Runtime.class);
            Mockito.when(myMock.exec(Mockito.anyString())).thenReturn(null);
            
			LightManipulationServiceHeyuImpl myService = BuildTarget(myMock);
			assertEquals(false, myService.toggleLight(new Light("asdf", "Fdsa"), true));
		}
	}
}

and class under test:

public class LightManipulationServiceHeyuImpl implements LightManipulationService {

	private Runtime _runtime;
	
	public LightManipulationServiceHeyuImpl(Runtime runtime) {
		if(runtime == null)
			throw new IllegalArgumentException("runtime");
		_runtime = runtime;
	}
	
	@Override
	public Boolean toggleLight(Light light, Boolean isOn) {
		try {
			return _runtime.exec("command") != null;
		} catch (IOException e) {
			return false;
		}
	}

	@Override
	public Boolean changeBrightness(Light light, int brightnessChange) {
		// TODO Auto-generated method stub
		return null;
	}
}

Obviously, I don’t want to execute the shell command “command”, but that’s tomorrow’s TDD. I’m happy for the evening, now that I’ve refactored an inline static Law of Demeter violation out of my design plans. :)

By

JUnit for C# Developers 5 – Delving Further into Mocking

Today, I’m continuing my series on unit testsing with JUnit with a target audience of C# developers.

Goals

These are today’s goals that I’m going to document:

  1. See about an NCrunch-equivalent, continuous testing tool for Eclipse and Java
  2. Testing the various complexities of the @PathVariable annotations
  3. Use mockito to perform a callback
  4. Mocking something that’s not an interface

On to the Testing

The first goal is more reconnaissance than anything else. I have come to love using NCrunch (to the point where I may make a post or series of posts about it), and I’d love to see if there is a Java equivalent. NCrunch uses extra cores on your machine to continuously build and run your unit tests as you work. The result is feedback as you type as to whether or not your changes are breaking tests. The red-green-refactor cycle becomes that much speedier for it. My research led me to this stack overflow page, and two promising leads: infinitest and ct-eclipse (presumably for “continuous testing”). I’m pleased with those leads for now, and am going to shelve this as one of the goals in a future post. Today, I just wanted to investigate to see whether or not that was an option, and then move onto concrete testing tasks.

Next up, for Spring framework, my toggleLight method’s parameters need to be decorated with the @PathVariable attribute, which apparently allows delimited strings in the Request Mapping’s value to be mapped to parameters to the method. In this fashion, I’m able to map a post request REST-style URL to a request for toggling a light. To accomplish this, I studied up and wrote the following test:

		@Test
		public void has_parameters_decorated_with_PathVariable_annotation() throws NoSuchMethodException, SecurityException {
			Class<LightController> myClass = LightController.class;
			Method myMethod = myClass.getMethod("toggleLight", String.class, String.class, String.class);
			Annotation[][] myAnnotations = myMethod.getParameterAnnotations();
			
			int myCount = 0;
			for(int index = 0; index < myAnnotations.length; index++) {
				if(myAnnotations[index][0] instanceof PathVariable)
					myCount++;
			}
			
			assertEquals(3, myCount);
		}

This failed, of course, and I was able to make it pass by updating my code to:

	@RequestMapping(value="/{room}/{light}/{command}", method=RequestMethod.POST)
	public void toggleLight(@PathVariable String room, @PathVariable String light, @PathVariable String command) {
		_lightService.toggleLight(null, command.toLowerCase().equals("on"));
	}

Note the @PathVariable annotations. I’m no expert here, but as I understand it, this takes variables in the mapping’s value delimeted by {} and maps them to method parameters. In order to do this, however, the parameters need this annotation. So cool, I can keep doing TDD even as I add the boilerplate for Spring MVC.

At this point, however, I want to verify that the service is being invoked with parameters that actually correspond to toggleLight’s arguments. Right now, we’re just hardcoding null for the light. (Between last post and this one, I did some garden variety TDD using the Mockito verify() previously available in order to resolve the logic about passing true or false to the service for the light’s value). Using verify(), I can make sure that I’m not passing a null light, but I have no means of actually inspecting the light. In the C#/Moq TDD world, to get to the next step, I would use the Moq .Callback(Action) functionality. In the Mockito/Java world, this is what I found:

@Test
public void calls_service_toggleLight_with_roomName_matching_room_parameter() {
	LightManipulationService myService = mock(LightManipulationService.class);
	LightController myController = buildTarget(myService);
	String myRoom = "asdf";
	myController.toggleLight(myRoom, "fdsa", "on");
	ArgumentCaptor<Light> myLightArgument = ArgumentCaptor.forClass(Light.class);
	
	verify(myService).toggleLight(myLightArgument.capture(), anyBoolean());
	
	assertEquals(myRoom, myLightArgument.getValue().getRoomName());
}

I’m creating an ArgumentCaptor object for lights and passing captor.capture() to verify(), which seems to work some magic for populating the captor’s value property with the light object passed to the service. I made this test pass, and then wrote another one for the light name, and wound up with the following code:

@RequestMapping(value="/{room}/{light}/{command}", method=RequestMethod.POST)
public void toggleLight(@PathVariable String room, @PathVariable String light, @PathVariable String command) {
	_lightService.toggleLight(new Light(room, light), command.toLowerCase().equals("on"));
}

I don’t know that this counts as a callback, but it is the functionality I was looking for.

So, at this point, I’m temporarily done with the controller. Now, I want to implement the the service and have it make calls to Runtime.getRuntime.exec(). But, in order to do that, I need to be able to mock it. As you know, in C#, this is the end of the line for Moq. We can use it to mock interfaces and classes with virtual methods, but static methods and other test-killers require Moq’s more powerful, heavyweight cousin: the isolation framework (e.g. Moles). So, I scurried off to see if Mockito would support this.

I did not have far to look. The Mockito FAQ offered the following as limitations of the tool: cannot mock final classes, cannot mock static methods, cannot mock final methods, cannot mock equals(), hashCode(). So, no dice there. We’re going to need something else. And, almost immediately, I stumbled on PowerMock, billed as an extension to Mocktio. “PowerMock uses a custom classloader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods, removal of static initializers and more.” You had me at “mocking of static methods.”

So, I downloaded powermock-mockito.1.4.11-full.jar and slapped it in my externaljars directory along with Mockito. As it turns out, I needed more than just that, so I downloaded the full zip file from the site, which was in a file named “powermock-mockito-testng-1.4.11.zip”. I ran into runtime errors without some of these supporting libraries. From here, I poked and prodded and experimented for a while. The documentation for these tools is not especially comprehensive, but I’m used to that in C# as well. This is what wound up working for me, as a test that my service was invoking the runtime’s executable:

@RunWith(Enclosed.class)
public class LightManipulationServiceHeyuImplTest {

	private static LightManipulationServiceHeyuImpl BuildTarget() {
		return new LightManipulationServiceHeyuImpl();
	}
	
	@RunWith(PowerMockRunner.class)
	@PrepareForTest(Runtime.class)
	public static class toggleLight {
		
		/**
		 * Make sure the service is invoking the runtime's exec() to invoke heyu
		 * @throws IOException
		 */
		@Test(expected=IllegalArgumentException.class)
		public void invokes_getRuntimes_exec() throws IOException {
			LightManipulationServiceHeyuImpl myService = BuildTarget();
			
			PowerMockito.mockStatic(Runtime.class); //We're going to set the mock's exec() up to throw an exception, and expect that exception
			Runtime myMock = Mockito.mock(Runtime.class);
			
			PowerMockito.doThrow(new IllegalArgumentException()).when(myMock).exec(Mockito.anyString());
			PowerMockito.when(Runtime.getRuntime()).thenReturn(myMock);
			
			myService.toggleLight(new Light("asdf", "Fdsa"), true);
		}

...

In the first place, I’d forgotten how much I loathe java’s checked exceptions, for all of the reasons I always did previously and now for a new one — they’re a headache with TDD. I mention this because I apparently need to have my test method throw that exception so that I can mock the runtime. (Not even use it — mock it). The rest of the stuff in there, I learned by experimentation. You have to include some new annotations, and you have to setup PowerMockito to mock the static class. From there, I created a mock of what Runtime.getRuntime() returns (not surprisingly, it returns a Runtime). Then, I setup the mock Runtime to toss an exception when its exec method is called — the one that I plan to use. I then expect this exception in the test. This is my clever (perhaps too clever) way of verifying that the exec() method is called in my class, without having tests that actually go issuing shell commands. That’d be a big bucket of fail, but I’d still like to test these classes and use TDD, so this is how it has to be.

Looking Ahead

Next time, I’ll work my way through developing this service and document anything that comes up there. These mocking frameworks are new to me, so it’s going to be a work in progress. I may or may not play with some of the continuous testing tools as well.

By

JUnit for C# Developers 4 – BDD, Mocks, and Matchers

This is yet another in my series of posts on using JUnit from the perspective of a C# developer.

Goals

Today, I have the following goals in my quest for JUnit TDD proficiency.

  1. Use a BDD-style testing scheme with nested classes.
  2. Use mocking framework to verify method call
  3. Use mocking framework to verify method call with parameters.

Getting to Work

First up, I’d like to see how to employ the test organization scheme described in this post by Phil Haack. The idea is that rather than simply having a test class per class under test, you’ll have a test class and nest within it a sub class for each method in the class under test.

Under Drew’s system, I’ll have a corresponding top level class, with two embedded classes, one for each method. In each class, I’ll have a series of tests for that method.

When you look at this in the test-runner, you see the same descriptive name, but the tests are better organized and can be run at another level of granularity. I’ve come to favor this style when I’m writing code in C#, and I thought I’d see how well it ported to JUnit. As it turns out, the test runner ignores the tests if you simply stick them in sub-classes. I poked around a little and discovered a post by Joshua Lockwood where he had the same idea and found a solution. I tried this out and it got me almost all the way there. I did need one minor tweak, however. (His post was written in 2008, so plenty may have changed in the interim). The “Enclosed” class that he uses required me to import “org.junit.experimental.runners.Enclosed”. By adding this line, I was off and running (though I did have to manually add the import as the IDE didn’t seem to find it):


package com.daedtech.daedalustest.controller;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

import java.lang.annotation.Annotation;
import java.lang.reflect.Method;
import org.junit.experimental.runners.Enclosed;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.util.Assert;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.servlet.ModelAndView;

import com.daedtech.daedalus.controller.LightController;
import com.daedtech.daedalus.services.LightManipulationService;

@RunWith(Enclosed.class)
public class LightControllerTest {

	private static LightController buildTarget() {
		return buildTarget(null);
	}
	
	private static LightController buildTarget(LightManipulationService service) {
		LightManipulationService myService = service != null ? service : mock(LightManipulationService.class);
		return new LightController(myService);
	}
	
	public static class Constructor {

		@Test(expected=IllegalArgumentException.class)
		public void throws_Exception_On_Null_Service_Argument() {
			new LightController((LightManipulationService)null);
		}
	}
		
	public static class light {
		
		@Test
		public void returns_Instance_Of_ModelAndView() {
			LightController myController = buildTarget();
			
			Assert.isInstanceOf(ModelAndView.class, myController.light());		
		}
		
		@Test
		public void is_Decorated_With_RequestMapping_Annotation() throws NoSuchMethodException, SecurityException {
			
			Class<LightController> myClass = LightController.class;
			Method myMethod = myClass.getMethod("light");
			Annotation[] myAnnotations = myMethod.getDeclaredAnnotations();
			
			Assert.isTrue(myAnnotations[0] instanceof RequestMapping);
		}
		
		@Test
		public void requestMapping_Annotation_Has_Parameter_Light() throws NoSuchMethodException, SecurityException {
			
			Class<LightController> myClass = LightController.class;
			Method myMethod = myClass.getMethod("light");
			Annotation[] myAnnotations = myMethod.getDeclaredAnnotations();
			
			String myAnnotationParameter = ((RequestMapping)myAnnotations[0]).value()[0];
			
			assertEquals("/light", myAnnotationParameter);
		}
	}
}

Notice the class annotation and the new static nested classes. These nested classes do have to be public and static for the scheme to work. In addition, it seems that once you use the “Run With Enclosed” paradigm, all tests must be in enclosed static classes to run. If you had some defined in the test class itself, the test runner would ignore them.

So, now that organization is better, onto more concrete matters. I now want to use my mocking framework to verify that a method was called. I want to add a method to the controller that takes a room name, a light name, and a text command (“on” or “off”) and issues a command to the service based on that. Using Mockito, I wrote the following test:

@Test
public void calls_service_toggleLight_method() {
	LightManipulationService myService = mock(LightManipulationService.class);
	LightController myController = buildTarget(myService);
	myController.toggleLight("asdf", "fdsa", "on");
		
	verify(myService).toggleLight((Light)anyObject(), anyBoolean());
}

The statement at the end is the equivalent of the “assert” here. I start out by building a mock using Mockito, and then I hand it to my overloaded builder, which injects it into my CUT. I perform (or will perform, since this method isn’t yet defined) an operation on the controller, and then I want to verify that performing that method resulted in a call to the interface’s toggleLight() method. The “any” parameters are known as “matchers” and they can be used in tests not just to see if a method on a collaborator was called, but with what kinds of parameters.

In the C# world, I use Moq and am a big fan of it. If you use this in C#, this whole paradigm should look pretty familiar. We create a mock, inject it, manipulate it, and verify it. Verify here is a static method that takes the mock as an argument, rather than an instance method of the mock, and mock creation is the same, but beyond that, these constructs look very similar, right down to the static “any()” methods for argument matching.

My final goal was to get to the point of using the aforementioned matchers to make sure the service methods were being invoked as I envisioned. To make the last test pass, I wrote the following “simplest possible” TDD code:

public void toggleLight(String room, String light, String command) {
	_lightService.toggleLight(null, false);
}

Since the unit test allowed for any Light object and any boolean to be the parameters, I opted for null and false, respectively. Doesn’t get much simpler than that. To advance my goals a bit, I know that when the command string passed to the method is “on”, I want to call the service with boolean parameter true. So, let’s see how that test would look:

@Test
public void calls_service_toggleLight_with_isOn_true_when_passed_command_on() {
	LightManipulationService myService = mock(LightManipulationService.class);
	LightController myController = buildTarget(myService);
	myController.toggleLight("asdf", "fdsa", "on");
	
	verify(myService).toggleLight((Light)anyObject(), eq(true));
}

It’s a nearly identical test, but this time around, notice that I’ve traded “anyBoolean()” for “eq(true)”. Now this test will only pass if the toggleLight() method calls the service with boolean true. the eq() static method returns a matcher for a specific value. Getting all tests to pass is pretty straightforward here:

public void toggleLight(String room, String light, String command) {
	_lightService.toggleLight(null, true);
}

Obviously, this method is pretty obtuse and needs some work, but I’ll get to that in the “off” command parameter case. The beauty of TDD is that you go from obtuse to rigor and accuracy by adding only the complexity you need in order to satisfy the next requirement. So, to recap, here is the current state of affairs of the controller:

@Controller
@RequestMapping("/light")
public class LightController {

	private LightManipulationService _lightService;
	
	public LightController(LightManipulationService lightManipulationService) {
		if(lightManipulationService == null) throw new IllegalArgumentException("lightManipulationService");
		_lightService = lightManipulationService;
	}

	@RequestMapping("/light")
	public ModelAndView light() {
		return new ModelAndView();
	}

	/**
	 * Toggles the light described by room and light names on or off (command)
	 * @param room - Name of the room we find this light in
	 * @param light - Name of the light itself
	 * @param command - Whether to turn the light on or off
	 */
	public void toggleLight(String room, String light, String command) {
		_lightService.toggleLight(null, true);
	}
}

and the test class:

@RunWith(Enclosed.class)
public class LightControllerTest {

	private static LightController buildTarget() {
		return buildTarget(null);
	}
	
	private static LightController buildTarget(LightManipulationService service) {
		LightManipulationService myService = service != null ? service : mock(LightManipulationService.class);
		return new LightController(myService);
	}
	
	public static class Constructor {

		@Test(expected=IllegalArgumentException.class)
		public void throws_Exception_On_Null_Service_Argument() {
			new LightController((LightManipulationService)null);
		}
	}
		
	public static class light {
		
		@Test
		public void returns_Instance_Of_ModelAndView() {
			LightController myController = buildTarget();
			
			Assert.isInstanceOf(ModelAndView.class, myController.light());		
		}
		
		@Test
		public void is_Decorated_With_RequestMapping_Annotation() throws NoSuchMethodException, SecurityException {
			
			Class<LightController> myClass = LightController.class;
			Method myMethod = myClass.getMethod("light");
			Annotation[] myAnnotations = myMethod.getDeclaredAnnotations();
			
			Assert.isTrue(myAnnotations[0] instanceof RequestMapping);
		}
		
		@Test
		public void requestMapping_Annotation_Has_Parameter_Light() throws NoSuchMethodException, SecurityException {
			
			Class<LightController> myClass = LightController.class;
			Method myMethod = myClass.getMethod("light");
			Annotation[] myAnnotations = myMethod.getDeclaredAnnotations();
			
			String myAnnotationParameter = ((RequestMapping)myAnnotations[0]).value()[0];
			
			assertEquals("/light", myAnnotationParameter);
		}
		
	}
	
	public static class toggleLight {
		
		@Test
		public void calls_service_toggleLight_method() {
			LightManipulationService myService = mock(LightManipulationService.class);
			LightController myController = buildTarget(myService);
			myController.toggleLight("asdf", "fdsa", "on");
			
			verify(myService).toggleLight((Light)anyObject(), anyBoolean());
		}
		
		@Test
		public void calls_service_toggleLight_with_isOn_true_when_passed_command_on() {
			LightManipulationService myService = mock(LightManipulationService.class);
			LightController myController = buildTarget(myService);
			myController.toggleLight("asdf", "fdsa", "on");
			
			verify(myService).toggleLight((Light)anyObject(), eq(true));
		}
	}
}

By

JUnit for C# 3 – Mocks and Other Niceties

Edit: It occurs to me that the name here was kind of an oops. If you’re here to see how I use JUnit while developing in C#, you’re probably going to be disappointed. I meant to title this “JUnit for C# Developers 3″, but made a rather comical omission. My apologies.

As I go along with this series of posts, I’ve come to a decision. My plan is to get my new, open source home automation server working at the level of functionality my old, struts-based one currently works. I think I’m going to muddle through TDD and posting my adventures for as long as that takes, and then I’ll probably add it to github to see if anyone wants to pull, and move on to other posting topics (like my practical design patterns series that I’ve been a little slow on lately). But, for now, I’ll keep on with these.

Goals for Today

Since my last two posts were more of a whim, I decided to get organized a little now that I’m in the swing of it. So, my goals for today’s post are the following:

  1. Find out whether or not Java now supports optional parameters.
  2. Figure out how to assert that a method throws an exception
  3. Figure out how to run a single unit test only
  4. Get setup with a mocking framework.

I figure that’s a bite-sized chunk for an hour or two, so let’s get started.

Actual Work

So, first up is Java and default parameters. The answer there seems to be a resounding “no” (it’s acquired foreach and instanceof, so I figured it was worth a shot). I saw this stackoverflow post, and upvoted the question while I was at it, but the answer seemed to be no. Given that the post was somewhat outdated, I checked around in some other places as well with the same findings. Bummer. The reason I wanted to find this out for my TDD is that I’ve adopted a pattern of doing something like this for my tests:

        /*
	 * This is here for TDD to stop me from needing to change every test
	 * if I decide to inject a xtor param
	 */
	private static LightController buildTarget(LightManipulationService service = null) {
		LightManipulationService myService = service != null ? service : new MockLightManipulationService();
		return new LightController(myService);
	}

Basically, instead of directly instantiating the class under test (CUT), I delegate that responsibility to this builder method. That way, if I decide to add a constructor parameter to the CUT, I don’t have to bother with the tiresome chore of updating all of my tests. And, adding a constructor parameter is a rather frequent occurrence for me when doing TDD.

But, it turns out that I’ll have to settle for the noisiness of a method overload to accomplish this. Perhaps its the purist in me, but I think default parameters in C# (and other languages) are a much more elegant solution to this problem than method overloads. I hate boilerplate code — it’s just more places you have to maintain and more places mistakes could be made. So, first goal accomplished, if not in a satisfying way. More on the builder and supplying an interface to the controller later.

Next up, I want to add a constructor parameter to my controller, as you may have intuited. The purpose of this light controller is to allow a user to turn lights in my house on and off with a RESTful URL scheme. The actual mechanics of lights on/off is accomplished via a shell command that invokes a driver my server is running. However, it is wildly inappropriate for a presentation layer controller to know the details of how that works, so I’m abstracting out a conceptual service:

public interface LightManipulationService {

	/**
	 * Turns the light in question on or off
	 * @param light - the light to toggle
	 * @param isOn - the setting (true for on, false for off)
	 * @return whether or not the operation was successful
	 */
	Boolean toggleLight(Light light, Boolean isOn);
	
	/**
	 * Change the brightness of a light
	 * @param light - the light to modify
	 * @param brightnessChange - the brightness change (positive for brighter, negative for dimmer)
	 * @return whether or not the operation succeeded
	 */
	Boolean ChangeBrightness(Light light, int brightnessChange);
}

“Light” is a POJO that I made to encapsulate properties for the room containing the light and the name of the light. The controller will operate by parsing the URL For the room and light parameters and then passing a corresponding light object to the service, which will take care of the actual light operations in a nod to the single responsibility principle.

Now, I want to inject an implementation of this interface into my controller and, furthermore, I want to throw an exception if a client injects null. After all, the controller for lights can’t operate in any meaningful way if it doesn’t have a service that actually does things to the lights. And this is where goal number (2) comes in. It turns out that testing for a thrown exception is pretty straightforward:

@Test(expected=IllegalArgumentException.class)
	public void constructor_Throws_Exception_On_Null_Service_Argument() {
		new LightController((LightManipulationService)null);
	}

That’s all there is to it. As an aside, I’m pretty impressed with Eclipse’s ability to take action during my TDD. For instance, when I instantiated the controller this way, I got a red won’t-compile squiggly as one would expect. As an option for fixing, I was allowed to declare a new constructor, ala CodeRush in Visual Studio (truth be told, VS may offer this too, but I’ve been using CodeRush for so long I don’t remember).

Now, my next goal was figuring out how to run an individual test, mostly for my own edification. Back to stackoverflow where I upvoted another question and answer:

In the package explorer unfold the class. It should show you all methods. Right click on the one method you want to run, then select Run As -> JUnit from the context menu (just tested with Eclipse 3.4.1). Also selecting “Run” on a single entry in the JUnit-results view to re-run a test works in the same way.

Sure enough, that did it. I can run it by right clicking the method or by highlighting it and using Ctrl-Shift-X, T. This is good enough for now, though what I’d really like is the ability that CodeRush and Visual Studio both confer to run a test with a key shortcut with my cursor inside the test. Perhaps that’ll be a goal for next time.

Now, for the meat of this post, a mocking framework. After getting that last test to pass, I now have a problem in that my code won’t compile, since I have another test that needs to inject something into the controller to get it to pass. For a mocking framework, I decided on Mockito. I chose this framework based entirely on “what did James Shore use in Let’s Play TDD”. My philosophy, generally speaking, is “get it working, optimize later”, so picking any framework and using it is better than deliberating long and hard. And, if a guy like James is using it, it’s probably worthwhile.

Installation was easy. I downloaded the jar from the download site and created a directory in my eclipse folder called “externaljars” where I placed it. I have no idea if this is a good practice or not, but a tutorial I looked at suggested creating a C:\mockito directory and I really prefer not to create clutter in root or anywhere else. Until someone tells me why not to, I’ll just stick these things in a sub-directory of Eclipse that I include in my build path.

So, next, I included this directory in my build path. :) From there, I just added the mockito import and defined an overload that I mentioned while fulfilling goal (1), and I had this CUT:

@Controller
@RequestMapping("/light")
public class LightController {

	public LightController(LightManipulationService lightManipulationService) {
		if(lightManipulationService == null) throw new IllegalArgumentException("lightManipulationService");
	}

	@RequestMapping("/light")
	public ModelAndView light() {
		return new ModelAndView();
	}
}

And 4 passing tests:


package com.daedtech.daedalustest.controller;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

import java.lang.annotation.Annotation;
import java.lang.reflect.Method;

import org.junit.Test;
import org.springframework.util.Assert;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.servlet.ModelAndView;

import com.daedtech.daedalus.controller.LightController;
import com.daedtech.daedalus.services.LightManipulationService;

public class LightControllerTest {

	private static LightController buildTarget() {
		return buildTarget(null);
	}
	
	private static LightController buildTarget(LightManipulationService service) {
		LightManipulationService myService = service != null ? service : mock(LightManipulationService.class);
		return new LightController(myService);
	}
	
	@Test(expected=IllegalArgumentException.class)
	public void constructor_Throws_Exception_On_Null_Service_Argument() {
		new LightController((LightManipulationService)null);
	}
	
	@Test
	public void light_With_No_Parameters_Returns_Instance_Of_Model_And_View() {
		
		LightController myController = buildTarget();
		
		Assert.isInstanceOf(ModelAndView.class, myController.light());		
		
	}
	
	@Test
	public void light_Is_Decorated_With_RequestMapping_Annotation() throws NoSuchMethodException, SecurityException {
		
		Class<LightController> myClass = LightController.class;
		Method myMethod = myClass.getMethod("light");
		Annotation[] myAnnotations = myMethod.getDeclaredAnnotations();
		
		Assert.isTrue(myAnnotations[0] instanceof RequestMapping);
	}
	
	@Test
	public void light_RequestMapping_Has_Parameter_Light() throws NoSuchMethodException, SecurityException {
		
		Class<LightController> myClass = LightController.class;
		Method myMethod = myClass.getMethod("light");
		Annotation[] myAnnotations = myMethod.getDeclaredAnnotations();
		
		String myAnnotationParameter = ((RequestMapping)myAnnotations[0]).value()[0];
		
		assertEquals("/light", myAnnotationParameter);
	}
}

Now, we’re getting somewhere! This class is going to be functional pretty soon!

By

Basic Unit Testing with JUnit for C# Developers 2

Last night, I posted about my adventures with TDD in Java from a C# developer’s perspective. As I start to shake my Java rust off a bit, I’m enjoying this more and more, so I think I’ll keep this series going for at least a bit, documenting some of my trials, travails, successes and failures. I don’t know that I intend to turn this into a long-running series, but I’m hoping to throw enough up to get a test-conscious C# developer off and running with Java.

Briefly, Some Good References

So, as part of this adventure, and to get off on the right foot, I’ve been referencing some external information. James Shore has been working on his blog series, “Let’s Play TDD” for over a year now. This is an excellent idea for those trying to get familiar with TDD as a practice. For me, I’m more interested in seeing the simple mechanics of testing in Java, such as where the handiest place to put the JUnit window is. Seriously. It sounds lame, but watching video of someone unit test in Eclipse is incredibly helpful for showing me little details that I’ve been missing and wouldn’t have thought to google.

Another reference is Jakob Jenkov’s tutorial on reflection for Java annotations. If you’ll recall, I mentioned this last time and, as it turns out, this, like many thing in life is possible. So, on that note and without further ado, here’s some code!

And Now For the Code!

	@Test
	public void light_Is_Decorated_With_RequestMapping_Annotation() throws NoSuchMethodException, SecurityException {
		
		Class<LightController> myClass = LightController.class;
		Method myMethod = myClass.getMethod("light");
		Annotation[] myAnnotations = myMethod.getDeclaredAnnotations();
		
		Assert.isTrue(myAnnotations[0] instanceof RequestMapping);
	}
	
	@Test
	public void light_RequestMapping_Has_Parameter_Light() throws NoSuchMethodException, SecurityException {
		
		Class<LightController> myClass = LightController.class;
		Method myMethod = myClass.getMethod("light");
		Annotation[] myAnnotations = myMethod.getDeclaredAnnotations();
		
		String myAnnotationParameter = ((RequestMapping)myAnnotations[0]).value()[0];
		
		assertEquals("/light", myAnnotationParameter);
	}

These are two new tests that I added. The first one reflects on the light controller class, seeing if the light() method has an annotation of type RequestAttribute. The second test takes it a step further and sees if the first value of request mapping is “/light” (this is the base URL to which I’m going to map).

And, here is the updated code that this drove:

@Controller
@RequestMapping("/light")
public class LightController {

	@RequestMapping("/light")
	public ModelAndView light() {
		return new ModelAndView();
	}
}

All I added was the annotation to light(). And this, unlike the last, more contrived example, I did in true TDD fashion. At this point, I should mention that I found a stack overflow question about whether or not testing for the presence of annotations made sense. Accepted answer seemed to say that it’s fine with a couple of dissenting responses below that.

Personally, as a mild digression, I find the dissent baffling, particularly if those people are familiar with TDD. I’m looking at my light controller class, which needs an annotation to work properly within the Spring MVC framework. It doesn’t currently have one. So… case closed. If I’m following TDD in earnest, I cannot go adding this without a red test. Uncle Bob is pretty clear on this point in his three rules of TDD: “You are not allowed to write any production code unless it is to make a failing unit test pass.” Now, I fancy myself more purist than pragmatist, so the reasoning behind this that speaks to me is that this is a testable alteration I’m making to my class, so why wouldn’t I test it?

Java-Things I’ve Learned

Here are a few random things I learned during tonight’s foray into Java TDD:

  • A more traditional import for asserts is org.junit.Assert.*;
  • “import static” versus just import allows me to use static methods without a qualifying type or being a child class of the class containing the static method. This feels icky to me, like C# extension methods, but I’m grudgingly using it for now with my tests and assert (I may revert to traditional import).
  • Java has a foreach loop: (for myString : someStringArray). During my last go-round with Java, I’m pretty sure that this didn’t exist yet.
  • Java has isinstanceof keyword. For my fellow C# travelers, here is your version of if(x is Foo)

By

Basic Unit Testing with JUnit for C# Developers

As I’ve blogged previously, I’ve become increasingly dependent on TDD to the point where I’m basically addicted to the practice. I start to get nervous and twitchy if I’m writing code that isn’t driven by tests — it feels like putting a mop into a bucket of filthy water and then using it to ‘clean’. In other words, writing code without tests feels like pushing dirt around aimlessly while having no positive effect.

But, I digress. The purpose of this post today is to document my implementation of TDD in Java using JUnit, coming from two solid years of almost exclusive C# work. So, bear in mind that I may make some mistakes here or violate some best practices (and feel free to comment and correct me), but it’s my hope that I get the basics right and perhaps can help someone else going from C# to Java.

First Things First

I won’t go into a lot of detail here, but I’m using Eclipse and have set myself up for Spring development. I had created a small, working Spring web app, and I had a little code here, but wanted to test first with any new code. To do this, I followed my C#/Visual Studio instincts and went to create a separate project containing my tests. About 85% of people from a smattering of languages favored this approach in a poll by Phil Haack, and the approach earned an answer and a vote, if not top honors, on stackoverflow.

When you go this route in Eclipse, there is no JUnit project to create, so you just create a standard java project. I did this and populated it with a directory structure mirroring that of my actual application, putting the tests in the ‘same’ package as their class under test counterparts. And then, really all that was needed was to import the org.junit.Test library which, apparently, was already wherever it needed to be (I realize that this is not helpful if you don’t have it, but this really isn’t the emphasis of this post).

Onto the Tests

The first thing I did was to create a class called LightControllerTest, as I was interested in creating a LightController class. And, I need that class to have a method called light() that would return a ModelAndView. So, I created the following test:

package com.daedtech.daedalus.controller;

import org.junit.Test;
import org.springframework.util.Assert;
import org.springframework.web.servlet.ModelAndView;

public class LightControllerTest {

	/*
	 * This should return an instance of model and view (apparently)
	 */
	@Test
	public void light_With_No_Parameters_Returns_Instance_Of_Model_And_View() {
		
		LightController myController = new LightController();
		
		Assert.isInstanceOf(ModelAndView.class, myController.light());		
		
	}
}

A few things to note here, fellow C# developers. One is that the equivalent of MSTest [TestMethod] is the java @Test annotation. This tells the test runner that this is a unit test. Another thing to note is that I’m using the spring framework’s assert, which may not be applicable if you’re not using Spring MVC. There is also JUnit’s assert available to you. I chose the Spring one because it had isInstanceOf(), which reminded me of MSTest’s “Assert.IsInstanceOfType()”.

So, with my test written and not compiling, I wrote the following code:

package com.daedtech.daedalus.controller;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.servlet.ModelAndView;

@Controller
@RequestMapping("/light")
public class LightController {

	public ModelAndView light() {
		//return new ModelAndView();
		return null;
	}
}

Now, I was primed to have a red test instead of a non-compiling one, but I needed to run the test itself. In Eclipse, there are various ways of doing it, but the closest I could come to Ctrl-R, T was Alt-Shift-X, T. Good enough – that seems to scope them the way MSTest does as well, with only the one test running, even though I defined another in a different class. But, as with Visual Studio, there are a number of different ways to run the tests — from the little green “play” button dropdown, from the context menu right clicking on the project, from within the JUnit window that appears once you run the tests, etc. So, I ran the test, saw it fail, and deleted the return null line in favor of the one that would make it pass. A little contrived, I realize, but you’ll have to cut me a bit of slack as I iron out the early kinks. Later, I’ll write tests that fail before they pass — I promise.

I’ll have to play for a bit to get myself really familiar with the ins and outs, and I’ll probably follow with more posts like this. I’m also going to be muddling my way through other random issues like “is it appropriate (or even possible) to test that a method is annotated” and “is there anything like NCrunch for Java/Eclipse”? Stay tuned! :)

Acknowledgements | Contact | About | Social Media