DaedTech

Stories about Software

By

Recognizing Test Smells

Tonight, I was plodding through the process of getting to know MongoDB and its java driver, TDD style. This is an interesting experience, as most of one’s development is going to involve technologies with which one is familiar and working out designs. This is classic problem isolation — all of your tools are familiar, and you have only to work out the design itself. In this case, I have two problems – the technology and the design aren’t familiar. In situations like this, it’s even more important to follow your nose when it comes to smells in code or tests, as you’re really flailing around in the dark. These may be the only things that guide a technology initiate to good practice short of taking a class or reading some books (and even then, they’re important, because you can only learn so much without getting your hands dirty.

Read More

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 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 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

Are Unit Tests Worth It?

The Unit Test Value Proposition

I gave a presentation yesterday on integrating unit tests into a build. (If anyone is interested in seeing it, feel free to leave a comment, and I’ll post relevant slides to slideshare or perhaps make the power point available for download). This covered the nuts and bolts of how I had added test running to the build machine as well as how to verify that a delivery wouldn’t cause unit test failures and thus break the build. For background, I presented some statistics about unit testing and the motivations for a test-guarded integration scheme.

One of the questions that came up during Q&A was from a bright woman in the audience who asked what percentage of development time was spent writing unit tests for an experienced test writer and for a novice writer. My response to this was that it would be somewhat slower going at first, but that an experienced TDD developer was just as fast doing both as a non-testing developer in the short term and faster in the long term (less debugging and defect fixing). From my own personal experience, this is the case.

She then asked a follow up question about what kind of reduction in defects it brought, and I saw exactly what she was driving at. This is why I mentioned that she is an intelligent woman. She was looking for a snap-calculation as to whether or not this was a good proposition and worth adopting. She wanted to know exactly how many defects would be avoided by x “extra” days of effort. If 5 days of testing saved 6 days of fixing defects, this would be worth her time. Otherwise, it wouldn’t.

An Understandable but Misguided Assessment

In the flow of my presentation (which wasn’t primarily about the merits of unit testing, but rather how not to break the build), I missed an opportunity to make a valuable point. I wasn’t pressing and trying to convince people to test if they didn’t want to. I was just trying to show people how to run the tests that did exist so as not to break the build.

Let’s consider what’s really being asked here. She’s driving at an underlying narrative roughly as follows (picking arbitrary percentages):

My normal process is to develop software that is 80% correct and 20% incorrect and declare it to be done. The 80% of satisfied requirements are my development, and the 20% of missed requirements/regressions/problems is part of a QA phase. Let’s say that I spend a month getting to this 80/20 split and then 2 weeks getting the rest up to snuff, for a total of 6 weeks of effort. If I can add unit testing and deliver a 100/0 split, but only after 7 weeks then the unit testing isn’t worthwhile, but if I can get the 100/0 split in under 6 weeks, then this is something that I should do.

Perfectly logical, right?

Well, almost. The part not factored in here is that declaring software to be done when it’s 80% right is not accurate. It isn’t done. It’s 80% done and 20% defective. But, it’s being represented as 100% done to external stakeholders, and then tossed over the fence to QA with the rider that “this is ‘done’, but it’s not done-done. And now, it’s your job to help me finish my work.”

So, there’s a hidden cost here. It isn’t the straightforward value proposition that can be so easily calculated. It isn’t just our time as developers — we’re now roping external stakeholders into helping us finish by telling them that we’ve completed our work, and that they should use the product as if it were reliable when it isn’t. This isn’t like submitting a book to an editor and having them perform quality assurance on it. In that scenario, the editor’s job is to find typos and your job is to nail down the content. In the development/QA work, your job is to ensure that your classes (units) do what you think they should, and it’s QA’s job to find integration problems, instances of misunderstood requirements, and other user-test type things. It’s not QA’s job to discover an unhandled exception where you didn’t check a method parameter for null — that’s your job. And, if you have problems like that in 20% of your code, you’re wasting at least two people’s time for the price of one.

Efficiency: Making More Mistakes in Less Time

Putting a number to this in terms of “if x is greater than y, then unit testing is a good idea” is murkier than it seems because of the waste of others’ time. It gets murkier still when concepts like technical debt and stakeholder trust of developers are factored in. Tested code tends to be a source of less technical debt given that it’s usually more modular, maintainable, flexible, etc. Tested code tends to inspire more confidence in collaborators as, you may run a little behind schedule here and there, but when things are delivered, they work.

On the flipside of that, you get into the proverbial software death march, particularly in less agile shops. Some drop-dead date is imposed for feature complete, and you frantically write duct-tape software up until that date, and then chuck whatever code grenade you’re holding over the QA wall and hope the shrapnel doesn’t blow back too hard on you. The actual quality of the software is a complete mystery and it may not be remotely close to shippable. It almost certainly won’t be something you’re proud to be associated with.

One of my favorite lines in one of my favorite shows, The Simpsons, comes from the Homer character. In an episode, he randomly decides to change his name to Max Power and assume a more go-getter kind of identity. At one point, he tells his children, “there are three ways of doing things: the right way, the wrong way, and the Max Power way.” Bart responds by saying, “Isn’t that just the wrong way?” to which Homer (Max Power) replies, “yes, but faster!”

That’s a much better description of the “value” proposition here. It’s akin to being a student and saying “It’s much more efficient to get grades of C and D because I can put in 10 hours per week of effort to do that, versus 40 hours per week to get As.” In a narrow sense that’s true, but in the broader sense of efficiency at being a good student, it’s a very unfortunate perspective.  The same kind of nuanced perspective holds in software development.  Sacrificing an objective, early-feedback quality mechanism such as unit tests in the interests of being more “efficient” just means that you’re making mistakes more efficiently.  And, getting more things wrong in the same amount of time is a process bug — not a feature.

So, for my money, the idea of making a calculation as to whether or not verifying your work is worthwhile misses the point.  Getting the software right is going to take you some amount of time X.  You have two options here.  The first option is to spend some fraction of X working and then claim to be finished when you’re not, at which point you’ll spend the other portion of the fraction “fixing” the fact that you didn’t finish.  The second option is to spend the full time X getting it right.

If you set a standard for yourself that you’re only going to deliver correct software, the timelines work themselves out.  If you have a development iteration that will take you 6 weeks to get right, and the business tells you that you only get 4, you can either deliver them “all” of what they want in 4 weeks with the caveat that it’s 33% defective, or you can say “well, I can’t do that for you, but if you pick this subset of features, I’ll deliver them flawlessly.”  Any management that would rather have the “complete” software with defect landmines littering 33% of the codebase than 2/3rds of the features done right needs to do some serious soul-searching.  It’s easy to sell excellent software with the most important 2/3rds of the features and the remaining third two weeks out.  It’s hard to sell crap at any point in time.

So, the real value proposition here boils down only to “do I want to be adept at writing unreliable software or do I want to be adept at writing software that inspires trust?”

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 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 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 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 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));
		}
	}
}