Three steps to getting a component displayed (assuming that there is a subclass of JPanel being used):

1) add a reference to the component to the subComponent
assertNotNull(container.subComponent);

2) Check that the component has the right stuff
assertEquals(“expected text”, container.subCompoent.getText());
etc…

3) Check that the component is going to be visible on the screen
assertEquals(container, container.subComponent.getParent()).

In practice for me I have added another panel to the containment hierarchy in order to use a JGoodies builder to do the laying out. This means that I have made the assert:
assertEquals(container.jgoodiesPanel, container.subComponent.getParent()).

I have also got an assertion that looks like this:
assertEquals(container, container.jgoodiesPanel.getParent()).

This ensures my JGoodies panel is made visible.

After doing this I can do the visual check to make sure it performs as expected. Which it does .

Just finished working out which layout managers in a Swing App that I have been building.

I have got a JSplitPane with a tree on the left, and then another panel on the right where stuff gets displayed.

It was a bit of a pain working out what I wanted the panel in the right to have as a LayoutManager. The thing that made it interesting is that the component for the right panel is dynamically decided, and can be either a JLabel, or a JPanel.

After googling, and playing with different layout managers (JLooks, etc), and reading sun’s stuff. I have ended up having a nasty little bit of code that programmatically decides between two different layout managers. This is a bit of a hack, that is there because of the difference in behaviour that I want to have happen.

When I am displaying a JLabel, I want to respect the size of the JLabel, and display it horizontally centered near the top of the page (I use a FlowLayout for this).

When I am displaying a JPanel I want it to fill up the entire right side of the screen (BorderLayout is good for this usecase).

Like I mentioned, this is a bit hacky, but does the job really well. I get the right layout behaviour when I need it (without adding extra Panels). When there is a JLabel, its size is respected, and a JPanel uses all the space available to it. It looks nice on screen.

On my work machine I have been having problems with ctrl alt l not working. I have tried working around this, mapping commands to ctrl-alt-k instead, but was not happy with the hack….

I spent a bit of time on Google, and found this. Now while I don’t use any polish keyboard shortcuts, I did find it fixed the problem .

I have just started reading Dave Astels book on TDD.

He talks about the fact that when working in Java, the first step is to make the tests compile, and that IDEs help to do that.

He also mentions that in a method that has a return type you must return something. This is mostly correct, but doesn’t match what I have found to be a very useful approach. I am going to jump into java 101 quickly to help describe what I do.

A java method with a return type must return something of that type, or throw a Throwable. The Throwable(Exception) needs to be of a type mentioned in the throws clause of the method signature, or it needs to be an Unchecked exception.

This brings me to my point….

When I am writing the method stub required to make a test compile, I make it throw an Unchecked Exception. This makes it pretty obvious that this has not been implemented.

I have been using something like this:

public boolean isSomething(){
throw new NoSuchMethodError(“Has not been implemented”);
}

I find this communicates better where the code is at than:

public boolean isSomething(){
return false;
}

I have updated my intelliJ code templates to do this.

(ctrl-alt-s, n, code, New method body)

After getting some interesting feedback from my question about TTD Swing code, and reading some of the literature out there, I have come up with an approach that I plan on following for my Swing development efforts.

I have boiled it down here to three main principles that I will follow:

1) write failing tests before adding components a panel.
2) use a thin view.
3) use mock objects.

I particularly like the intersection of “The Humble Dialog Box” and xp123.com articles. I like the idea of adding the components to a panel subclass in a pure TDD way. I get to feel more relaxed in knowing that the production code I am writing is being written to make a test compile and pass. I probably wonít end up testing the layout management of this, but will have the components tested, and the confirmation that key components are there.

Everyone (Ian, Stuart, testdriven.com, past experience, design patterns), agrees that having a really thin view is a good thing (TM). This is a good way of mitigating the risk of any damaging impacts caused by untested code in the view.

The final key part of my strategy will be the use of Dynamic Mock objects. I am a big fan of dynamic mock objects, particularly fond of the uniform API for setting expectations that they give. I am going to use JMock for this. It also has mocking of classes as well as interfaces, which can come in handy when testing 3rd party code.

After reading over what I just said, and Ian Bourkeís comment, I think I have come to pretty much the same approach as he suggested. It pays to listen to the smart people around you .

The Ant File Scanners can be a useful tool for Java developers, and can be called programmatically quite easily. I have done it a couple of times for writing simple development tools. I don’t bother writing ant tasks, but just have programs that depend on the ant jar being available.

I have just started using FIT for my acceptance tests. I am waiting for tools that hook into fit to be released, but in the meantime wanted an easy way of running all my fit tests at once.

The org.apache.tools.ant.DirectoryScanner class that implements the org.apache.tools.ant.FileScanner interface is great for doing things like this. It lets you specify:

a base directory void setBasedir(String s);
an array of includes patterns void setIncludes(String[] strings);
an array of excludes patterns void setExcludes(String[] strings);

After doing this you can .run the scanner void scan();, and see the results:
String[] getIncludedFiles();

I have put the source code for my FIT test runner here:
FitTestRunner.java

ps – I would have loved to have linked to the ant java doc for their classes, but this was not possible at the time of publishing this — the link on ant.apache.org was bad.

I am on the search for Swing code that has been developed TDD.

I would like to get people’s experience, and see some source code.

Ideally I want to see an open source project for a swing client that has been developed test driven.

I am doing some Swing coding and am finding that it is easy to not do the client part Test Driven, and want to see some code that does it to help me decide how useful doing the Swing parts Test Driven is going to be. In my past experience I have found that it is possible to write any code that I want Test Driven, but sometimes this can be hard. I have also found that there are a number of cases where just because it is hard to do it test driven doesn’t negate the fact that it is useful.

I am looking for some Test Driven Swing code to help make that decision with Swing.

Please add comments if you know of any Swing code that I can see that has been developed Test Driven. I’ll post any useful findings that come from this.