One of our senior developers is putting together a class mostly based on Head First Java, 2nd Edition. The class will reinforce the basic language concepts for several of our developers who feel they still don’t quite get the point of inheritance or how an inner class works.

The developer explained that he was writing all the example code with JUnit and that Head First Java 2nd Edition has test classes and even mentions a process to follow of:

• Prep for coding.
• Test
• Code

For some reason though they don’t follow through and just show you JUnit and instead end up writing main method test classes. Still it’s by far the best Java beginner book, I just wish they went ahead and introduced people to JUnit.

Monday morning team meetings at 9:00am suck even more. Fortunately after ten weeks of 9am team meetings I’m moving my team meetings back to Tuesday at 10am.

For would be managers who are thinking about running team meetings on a Monday, my advice would be–don’t. A few reasons:

• Most people don’t show up to work Monday morning bright eyed and bushy tailed. They will typically tune out much of what you’re saying.
• I have to rush to prepare the agenda unless I was clever enough to put it together on Friday.
• I haven’t had my weekly staff meeting with my boss so most corporate stuff will be at least a few days old.

My experience over the ten weeks was average attendance was maybe 75% instead of closer to 90%. Often this was because 9am is when about half of my staff typically shows up since they are dropping off kids at school and such. I got very few questions and people looked happy when the 30 minute meeting finished early. I often felt ill prepared because I had to rush my prep for the meeting. It just takes a little while to ease into the work week for most humans.

Now that our 10 week security training is over I’m looking forward to a nice Tuesday staff meeting.

Dan Bunea recently posted on doing TDD with a web application. Since I’m currently cobbling together a similar TDD JSF example to use for a seminar in my organization I found Dan’s approach enlightening.

Dan begins at the completely at the front end writing a Selenium test against the initial page of an application where you add a user. He then builds the ASP pages in this case since it’s a .NET example and goes on to dig through the controller and business layers testing all the way to the database. He goes ahead and writes an integration test that tests the database during this process.

The integration test isn’t pure TDD, but I’ve taken the same approach in regards to my example so far instantiating an in-memory database with HSQLDB because I don’t really feel the need to rely on mocks to test my service and DAO objects.

I also differ in that I started at the controller and worked my way back, only developing the UI as a last step. My favorite approach is to try and ignore the GUI when doing development until the last step, though many people find that starting with the visual GUI layer is an easier starting point.

All in all a fairly good example of how you might approach TDD on a webapp.

A rather humorous exchange happened today at a standup:

The subtext is this is on a project with only a handful of unit tests at all. Of course it’s both in a portal and using JSF which makes setting up the context to test something like a JSF backing bean a major pain. Since they haven’t really had many tests much of the team doesn’t see that much of a point in spending the considerable effort to at least put in some sort of a test harness with Fitnesse tests.

I did point developer #1 in the direction of hooking Fitnesse up to the service layer which are just plain old POJOs. This should make the testing the business logic a lot easier. He really wanted to use Fitnesse to do an end to end test, but I explained that there was much more bang for the buck in hooking in below the view layer instead of trying to mimic it.

Spent some time watching a screencast by Brian Marrick on Model-View-Presenter instead of Model-View-Controller. It would appear from the screencast that views have everything possible scraped out and popped into the presenter. It uses the Observer pattern and simply fires off events when things like buttons are pressed. The view layer is very thin made up mostly of getters and setters and probably is to simple to bother testing. The presenter is listening for events and acting on them. Code you might actually want to test goes into the Presenter layer.

When I have some time I think I may need to dig into an actual example to get the idea.