Archive for August 2006
Today I taught my very first class, which was the first in a series of training sessions I plan on presenting at my workplace on fitnesse. Fitnesse (and acceptance testing) is a very interesting topic to discuss on my team, as unfortunately the team was mandated to use it without being given any genuine, formal training on the subject.
The result has been much much grief. This week I and a few others were tasked with fixing broken acceptance tests, which tested the right thing, but were very fragile. For example, due to the lack of knowledge of symbols or fixtures for flow processes like DoFixture or ActionFixture, alot of the tests contain ad hoc ColumnFixtures that use static members to communicate with each other, and 7 levels of heiarchies between fixtures to reuse logic, despite how unrelated. This has led to problems as the tests themselves are fragile and don’t work well when ran together in suites (thanks to shared static members).
No tags
16
Getting Your Custom JUnit TestCase Ignored by Eclipse
No comments · Posted by James Carr in Uncategorized
One issue I’ve struggled with lately is a small problem in eclipse caused by a custom TestCase class I created that extends TestCase that has special assertions. When I right click on my unit test page and run as junit test to run all my unit tests, I always get red bar and it complains about my custom TestCase class because it has no tests in it.
Anyhow, it seems I have finally found the solution! All I had to do was make my special TestCase abstract and eclipse ignores it. Now, after months of seeing red and being acquainted with “good red bar” and “bad red bar”, I can now once again experience the joy of seeing green.
No tags
For about 8 months now, I have had so many problems with my Dell Inspiron 1100 it wasn’t funny. Sometimes it got very very slow, it was always scorching hot, and occasionally it shut itself off from overheating if left unattended. It’s also been a piece of crap … in the year and half I have had it, the casing is cracked and the keys are beginning to see wear and tear, some hardly working. And despite a 512mb memory upgrade, it’s still slow as snot and chokes on video.
Anyhow, I wasn’t surprised today to see that Dell is
issuing a recall for laptops, and my model is included in the recall.
About time.
The Sydney Morning Herald also has a few interesting words on this.
No tags
14
Are Too Many Mocks A Code Smell?
1 Comment · Posted by James Carr in Agile Software Development, Test Driven Development
Recently I have been involved in an excellent discussion the testdrivendevelopment yahoo mailing list regarding a concearn I had over whether using expectations with mock objects cause you to violate encapsulation, and received very many good replies, and during the thread one of the authors of RMock stated that :
I think when using mocks, absurd abmounts of setup code is an indication that your design could be improved. I have no concrete
metrics for you but I would stat looking if I can simplify my design if I require more than 10 or so lines of setup. Sometimes it is hard. Usually you are doing too much at the time and then srp can be your guide.
To which I found to be quite true. At that time the conversation had drifted to whether or not mocks can sometimes slow you down with too much setup code, as my partner and I were dealing with a test we were writing that had an insane amount of mocks and setup. However, that same day we discovered that, yes, our object we had under the test had too many responsibilities and few collaborators. Once we broke these responsibilities out into seperate objects and refactored our unit test to move responsibilities to the tests for those objects, we discovered something. The setup reduced dramatically, and at the same time some of our newer objects no longer even needed mocks as they were no longer forced to “touch” the responsibilities that used those objects.
No tags
10
AssertThat() and Other RMock Goodies
No comments · Posted by James Carr in Agile Software Development, Test Driven Development
This week we’ve been using RMock quite a bit to try and do “true” unit tests, which I have been trying to follow the 5 rules of a unit test that Michael Feathers describes:
A test is not a unit test if:
1. It talks to the database
2. It communicates across the network
3. It touches the file system
4. It can’t run correctly at the same time as any of your other unit tests
5. You have to do special things to your environment (such as editing config files) to run it.
Anyhow, recently I discovered how to do constrains in RMock and how to use assertThat to do more informative and interesting assertions. One useful feature I found was for a method where I test that it creates an instance of an object using reflection. Although I had it returning an interface, I also wanted to check to make sure that it was an instance of the actual object I was looking for.
assertThat(person, is.instanceOf(Person.class);
Another instance I found using assertThat useful was cases where I want to see that just a substring of text is present in a return value. Rather than having too fool around with the somewhat unclear and dirty
assertTrue(returnValue.indexOf("was found") > -1);
I can instead assert
assertThat(returnValue, is.containing("was found"));
which is much much more clearer.
The is attribute of RMockTestCase includes a long list of usefule features and constants that can be used in assertThat(), such as is.ANYTHING, is.eq(), is.lt(), is.gt(), is.not(), and many more I have not explored yet.
But that’s not all! Not only have these been useful with assertThat, they’ve also been very useful to use with mock objects when setting up their expectations. For example, in one case I didn’t want to test the exact value that a method call received, but rather satisfy conditions that (a) it was called with the specified classes, and (b) contained a range of values. For Example:
public void testConstraints(){
Map foo = (Map) mock(Map.class);
foo.put(null, null);
modify().args( is.instanceOf(String.class).and(is.ANYTHING),
is.instanceOf(Integer.class).and(
is.gt(5).and(
is.lt(20))));
startVerification();
foo.put("BOO", new Integer(6));
}
However, the following fails:
foo.put("BOO", new Integer(4));
I’ll write more on this later.
No tags
9
Partial Mocks (or Stubs) With RMock
No comments · Posted by James Carr in Test Driven Development
Recently I wanted to be able to do something I had done for quite awhile using Simpletest in PHP … create partial mocks that mock out just a specified method on an object and replace it with canned data (a stub). So far I hadn’t found something to let me do this in the java world short of subclassing the actual object and overriding the method in an inner class. I’ve been against doing that for the most part because I believe mocks should be dynamic rather than hard coded, although where this belief comes from is beyond me.
No tags
2
Customer Communication
No comments · Posted by James Carr in Agile Software Development, Thoughts
Martin Fowler recently made an interesting post on his Bliki titled Customer Addinitiy in which he discusses the importance of a developer being able to communicate effeciently with their customer, and I couldn’t agree more.
To me, on a scale of 1 to 10, customer communication ranks a strong 10, while actual technical skill ranks maybes somewhere around 5. There have been times I have seen horribly written software, with code so rank I wouldn’t want to look at it, yet at the same time the software was successful because the developers understood the requirements accurately through constant communication (not that I advocate poorly written code, of course!).
It’s interesting that Martin points out that one of the names Kent suggested for agile was conversational software development, emphasizing that communincation between client and developer is an involved, two way process. Through the process of constant feedback and communication with the customer, developers can be sure to sufficiently translate the requirements as well as be able to make rapid changes, as opposed to having to wait for email replies or the client reviewing the next release.
The other important point he emphasizes is similar to what Eric Evans states in Domain Driven Development … the developer must come to apperciate and understand the domain that their application is working with. Not that they need to be a domain expert, but it helps to understand aspects of the domain (I recall in the past when a client referred to something by one name, yet I understood it as something technical that really had little to do with the domain).
I have to say my favorite project was when I wrote a mortgage application system, which I communicated constantly with people on mortgage lender related mailing lists as well as people on the Mortgage Industry Standards Maintenance Organization mailing list. I learned so much I feel quite confident when the time comes to take out a mortgage on a new house.
No tags
