Code & Iron

Uncategorised

May 18, 2012

My First Experience with Programming

I saw a post at HackerNews the other day from Justin Kan about his first experience with programming. Short story: he was asked to do something over and over. The pain that he felt when asked to do this caused …

  Show More

I saw a post at HackerNews the other day from Justin Kan about his first experience with programming. Short story: he was asked to do something over and over. The pain that he felt when asked to do this caused him to learn and apply a VB macro in the background of an excel sheet. My own experience was quite similar, and dredging it up was a fun trip down memory lane.

I worked a few summers at a manufacturing company that made manifolds and nozzles for plastic injection molding machines. I had some great experiences there (designing wooden trays to hold nozzles), and some weird ones (spray painting some 1300 of said trays). I think I was 15 at the time.

On a normal Friday afternoon during my first summer there, my immediate boss asked me to come in and sit down with with the “Consultants”. These were the type of “Efficiency Experts” that made $200 an hour, and only told you things about your company you should already know. These lean-manufacturing gurus were trying to figure out how to create a Just In Time machine cell using the existing metal mills. They knew that these machines could only accept manifolds under 90cm in width. Anything larger than that (or thicker than some number I can’t remember) would have to be routed to larger machines outside the normal flow.

“Sit down, Matt. Here is the first 120 pages of some 23,000 unique manifold descriptors dumped out of SAP. We need you to make a list of those manifolds that CAN go into the machine cell, and those that can’t. This can’t be a simple sort, because sometimes the dimensions can look like blah235blah, and sometimes they can look like 983yadda84. It’ll probably take you 6 hours Saturday and Sunday, for the next 2 weeks.”

Shit. I’m in trouble and in danger of losing my weekend. Time to figure out what makes Excel tick. 3 hours, and a lot of if else if else if else if else copy paste later, I had the 23,000 manifolds sorted and grouped by size. I ended up with a thrown together, hideous, disgusting abomination of code that took 10 minutes to run once. But. It worked, and never again needed to see the light of day. I still have the excel file but I won’t post it for fear it will be used against me later 😀

“Here you go. See you next week!”

  Posted by Matt Holtom on May 18, 2012
May 18, 2012

Way Back When… My First Experience with Programming

I saw a post at HackerNews the other day from Justin Kan about his first experience with programming. Short story: he was asked to do something over and over. The pain that he felt when asked to do this caused …

  Show More

I saw a post at HackerNews the other day from Justin Kan about his first experience with programming. Short story: he was asked to do something over and over. The pain that he felt when asked to do this caused him to learn and apply a VB macro in the background of an excel sheet. My own experience was quite similar, and dredging it up was a fun trip down memory lane.

I worked a few summers at a manufacturing company that made manifolds and nozzles for plastic injection molding machines. I had some great experiences there (designing wooden trays to hold nozzles), and some weird ones (spray painting some 1300 of said trays). I think I was 15 at the time.

On a normal Friday afternoon during my first summer there, my immediate boss asked me to come in and sit down with with the “Consultants”. These were the type of “Efficiency Experts” that made $200 an hour, and only told you things about your company you should already know. These lean-manufacturing gurus were trying to figure out how to create a Just In Time machine cell using the existing metal mills. They knew that these machines could only accept manifolds under 90cm in width. Anything larger than that (or thicker than some number I can’t remember) would have to be routed to larger machines outside the normal flow.

“Sit down, Matt. Here is the first 120 pages of some 23,000 unique manifold descriptors dumped out of SAP. We need you to make a list of those manifolds that CAN go into the machine cell, and those that can’t. This can’t be a simple sort, because sometimes the dimensions can look like blah235blah, and sometimes they can look like 983yadda84. It’ll probably take you 6 hours Saturday and Sunday, for the next 2 weeks.”

Shit. I’m in trouble and in danger of losing my weekend. Time to figure out what makes Excel tick. 3 hours, and a lot of if else if else if else if else copy paste later, I had the 23,000 manifolds sorted and grouped by size. I ended up with a thrown together, hideous, disgusting abomination of code that took 10 minutes to run once. But. It worked, and never again needed to see the light of day. I still have the excel file but I won’t post it for fear it will be used against me later 😀

“Here you go. See you next week!”

  Posted by Matt Holtom on May 18, 2012
February 1, 2012

Over and Over: Parameterized Testing in JUnit

So you love creating meaningful test cases, right? You get jazzed about your software working, and even better; you can prove it. But here’s the issue: many of the test cases in that 100 page “test plan” are data-driven. You …

  Show More

So you love creating meaningful test cases, right? You get jazzed about your software working, and even better; you can prove it. But here’s the issue: many of the test cases in that 100 page “test plan” are data-driven. You find yourself creating the same test method over and over again with the only difference being the in’s and out’s. You don’t repeat yourself in the src/main directory, so why should it be okay in the src/test directory?

Don’t get W.E.T., D.R.Y. it up! No, there’s no need to create a .properties file of your data set to be read into the tests. Don’t you dare create a custom XML schema, XML files and parser. Stop right there! I see you over there creating your own XML-based testing suite. You aren’t the first person to try this… it’s been done, and done well!

The custom Parameterized runner in JUnit 4 is ideal for when you want to execute the same test method many times with varying inputs and varying expected outputs. Below I’ve set up a basic test class that confirms the operation of a web page that will sum any two values. It uses the Selenium Webdriver page objects pattern, but that’s a discussion for another day.

@RunWith(Parameterized.class)
public class ValidInputValueTests {
	
	private String inputValue1;
	private String inputValue2;	
	
	public ValidInputValueTests(String inputValue1, String inputValue2, String outputValue){		
		this.inputValue1 = inputValue1;
		this.inputValue2 = inputValue2;
                this.outputValue = outputValue;
	}	
	
	@Parameters
	public static Collection<Object&#91;&#93;> generateData() {
		return Arrays.asList(new Object[][] {				 
				 {"10.00", "", "10.00"},
				 {"10.00", "10.00", "20.00"},
				 {"", "10.00", "10.00"}
				 });
	}
	
	@Test
	public void TC2_4_2PerformThisTestForParameters(){		
		InputPage inputPage = certainNextPage.enterValuesAndClickNext(inputValue1, inputValue2);
		FinalPage finalPage = inputPage.enterStandardInfoAndSubmit();
		
		Assert.assertEquals("Actual value does not match expected value on finalPage", outputValue, finalPage.getResult());
	}
}

Instead I’ll discuss each part in detail as pertains to JUnit Parameterized tests. First off, import and add the annotation to RunWith the Parameterized custom runner from the JUnit 4 API. This is how JUnit knows to scan the test class for the @Parameters within it.

@RunWith(Parameterized.class)
public class ValidInputValueTests {

Next, the class must have a publicly visible constructor with the same number of arguments as parameters.

	public ValidInputValueTests(String inputValue1, String inputValue2, String outputValue){		
		this.inputValue1 = inputValue1;
		this.inputValue2 = inputValue2;
                this.outputValue = outputValue;
	}

Then tell JUnit where your parameters are residing by annotating a static method called generateData that returns a collection of object arrays (don’t ask, this is a weird quirk of the Parameterized class IMO). These will be injected into the test class constructor by Parameterized. To date I’ve only used Java standard types and primitives (Strings, boolean, etc.) as parameters and haven’t experimented with passing custom objects.

	@Parameters
	public static Collection<Object&#91;&#93;> generateData() {
		return Arrays.asList(new Object[][] {				 
				 {"10.00", ""},
				 {"10.00", "10.00"},
				 {"", "10.00"}
				 });
	}

Now let’s set up our test method. Note that you could put as many methods in this test class as you want. They will all be executed in turn with the set of parameters above, making the Parameterized runner VERY powerful, talking N X M powerful. It effectively generates a test method instance for every result in the cross product of parameter sets and test methods.

	@Test
	public void TC2_4_2PerformThisTestForParameters(){	
		...
		InputPage inputPage = certainNextPage.enterValuesAndClickNext(inputValue1, inputValue2);
		FinalPage finalPage = inputPage.enterStandardInfoAndSubmit();
		
		Assert.assertEquals("Actual value does not match expected value on finalPage", outputValue, finalPage.getResult());
	}

Note that in the above test method, we have access to our inputValue 1 and 2, and our output value, trusting in Parameterized.class to populate these variables with our test data.

So why not create some data driven tests for your system today! Super simple, super quick, super powerful, god I love JUnit.

Take care,
Matt

  Posted by Matt Holtom on February 1, 2012