Author Archives: mikeh

Acceptance Testing a Web Application – Part 2

In this episode we morph the simple acceptance test we wrote in the previous episode into an acceptance test that specifies what our application should do when quoting a stock price. We learn that sometimes initial acceptance tests are, in a sense, about exploration of the domain, and how to specify it, and that giving yourself permission to explore is important. We get to see what it means if an acceptance test can be satisfied with a hard coded implementation and why “Given/When/Then” is a sensible structure for such tests. We discover that test driving like this uncovers domain concepts and relationships, and we introduce “stubbing” to help us control our external environment.

When playing this video, make sure to play it fullscreen, so you can read the text.

Software development is deeply personal

“I think we should use Spring.”
“Over my dead body…”

“Maven is the only way to go.”
“Maven makes me want to hurt people…”

“I think we should have simple data objects and put all the logic in services.”
“No way, Eric Evans is a god and you need to read his bible…”

I’ve seen, heard and been involved in too many of these “discussions” recently. They’re wars really. I’ve not seen one come to a satisfying close. At best the warring parties walk away from each other without coming to blows, grumbling about how stupid is the other, and go on with whatever approach they happen to prefer anyway – the “right” way.

The damage from these kind of wars can be contained if they are across teams, but when they are between team members it can destroy the team. If half the team wants Spring, and the other half don’t, it can make for some very awkward pairing, “code wars”, terrible morale, and impaired productivity. And a loss of that very precious life experience – happiness.

For a long time this bothered me a lot, and I banged my head trying to find a solution. Surely there is some way “we can all just get along”? Well, recently I’ve stopped. I saw that there’s no point. There is no solution. Because there is no problem. Some people like Windows, some like Linux, some like OS X. Is there a solution to this? No, because its not even a problem. Its a blessing. A Linux die-hard could be a Linux die-hard for life, and good luck to them. Some people prefer BMW, some swear by Mercedes Benz, others by Skoda. Some people are Hindu, some are Protestant, others Muslim. Good luck to the lot of them.

Therefore, coming back to software development, its more important, in my mind, to be honest about a team’s tooling and development culture, and to hire members that fit.  If a team is all about Spring, there is no point hiring a developer who openly states that they hate it. If a team is all about domain driven design, there is no point hiring a developer that states that separating data objects and service objects is the only way to go.

And for you as an individual developer, you need to be honest with yourself and with others about what your instincts are, and find teams in which you’re a fit, rather than an annoyance. And if you do hate Spring (presumably with reason), be honest enough to say it. Have the courage of your convictions. There can be a fear accompanying this kind of personal honesty that makes you think “damn, if I say I hate Spring, maybe I won’t get this job I’m interviewing for. Or maybe they will think I am close-minded.” Well maybe you won’t get the job and maybe they will think you’re close-minded. As long as you know your reasons for hating Spring, then you can rest assured that you have made a personal, informed choice. As for not getting the job, well – phew! – you’ve saved yourself and the interviewing company much unhappiness, and you stand a chance of finding a team on which you’ll flourish.

One qualification that is essential to add, and which keeps open the door to development and learning, is this: any individual or team that finds themselves aligned to a particular approach must still be open to listening respectfully to advocates of other approaches, and maybe even being friends with them 🙂 Keep questioning and reading and studying and talking to people and trying things out, and stay honest with yourself, because at the end of the way, maturing as a software developer is never about becoming finally right, but by becoming increasingly less wrong.

Acceptance Testing a Web Application

In this episode we put in place the framework necessary to acceptance test a web application. The purpose of an acceptance test is explained. Then we evolve some code to start and stop our WAR file in embedded jetty, and drive the application using WebDriver, making some simple asserts. We check in and make sure it goes green on our continuous integration server.

When playing this video, make sure to play it fullscreen, so you can read the text.

Introducing Continuous Integration

Its easy to make mistakes when you’re checking in software to a source code control system. You can forget to include necessary files, you can break tests, you can introduce compilation errors. This is bad enough when you are working alone, but can be very annoying in a team context, as several people may have to down tools to locate a problem that may have been introduced days before it was found.

Continuous integration addresses this issue, but setting up an automated team member, a machine, whose sole purpose is to continuously check out the code, compile it, test it, and make sure its of the required quality.

This screencast explains all you need to know to get continuous integration understood and implanted as a practice with your team. It covers the following topics:

* where continuous integration fits in the software development process
* what problems it helps to solve or avoid
* what is a build server
* downloading and installing TeamCity
* build breakage notification strategies, especially large build monitors
* downloading and installing the Piazza TeamCity plugin
* and as a side issue, removing duplication in an ant file.

The quality of the text in the video is substandard. Subsequent videos are HD quality. Its best to watch in fullscreen.

Introducing Source Code Control

YouTube Preview Image
YouTube Preview Image
This episode of Software Success Disciplines talks about the essential component of source code control.  It comes in two parts.

The first part describes the theory of source code control, the benefits it offers, the kinds of processes it involves, and how it enables teamwork.  This information is communicated using a mix of “blackboard” sessions, and a simplistic on-disk model of what a source code control server might do internally.

The second part of the screencast settles on Subversion as our source code control tool of choice.  It talks about repository management, and then shows how to import your project, and check it out again so you can avail of Subversion facilities.

To best view the videos, watch them on YouTube. Right-click on one of the thumbnails above, and select “Watch on YouTube”.

Total run time: 15 minutes

Setting up a simple web application

YouTube Preview Image

The first few steps you take with a software project can have a huge influence on its success. This screencast shows you how to position your project for success by getting the basics right in “iteration zero”.

In the space of twenty minutes, we’ll go from having an empty directory to a deployed “Hello World” web application.

Along the way you will learn how to put in place a sensible directory layout, how to manage dependencies, how to do test driven development using JUnit and how to do automated building, testing and artifact (JAR and WAR) creation using Ant.

Audience: The screencast is intended for developers or team leads with little or no agile experience who are looking to get the basics in place.

Run time: 19 minutes

Update April 2010 I’m going to completely redo this video. It was the first one I did, and it was recorded in a noisy hotel room, so the quality is not up to scratch.

Software Success Disciplines Launched

I am delighted to announce that today I am launching a series of screencasts that attempt to get across a working method for software development teams that puts the odds of success in their favour.  The series is called Software Success Disciplines, and will also come in classroom form in the near future.

The practises are nothing new.  And yet they are not put in place in most software projects, as far as I can tell.  The screencasts will roll out over the following months, using the following as a kind of guide as to what will be covered:

* empty directory structure
* discuss directory layout and project naming
* put directory layout in place
* begin hello world test case
* discuss unit testing
* discuss frameworks (junit, testng)
* download and install junit
* Write test case
* Explain TDD
* Explain Red/green/refactor
* we need to run the test
* discuss build systems
* discuss options (ant/maven)
* download and install ant
* work through the ant file to compile and test
* compile and test
* turn into web application
* extend ant file to build WAR
* demo the WAR working
* clean up the ant file
* introduce the concept of source code control
* discuss options
* import project into subversion
* introduce the concept of continuous integration
* discuss options
* setup hudson and integrate our project
* begin a more complex project task – a stock quoting system backed
by yahoo.
* introduce mocking/stubbing
* write yahoo stock quoting stub by hand
* TDD the quoting service
* write a simple jsp to take the stock symbol and display the price.
* deploy and check
* introduce the concept of releasing, expecially releasing early and
often, and in an automated way
* introduce branching and tagging
* extend the ant script to enable release creation
* release
* introduce mocking frameworks and discuss options.
* download and install mockito
* rework previous test to use mockito stub instead of hand written
one.
* introduce acceptance testing
* discuss options
* choose concordion
* write acceptance test for previous work
* explain that this should be done first
* extend ant script
* demo the acceptance test failing
* make it green
* extend the project to include the idea of a User and a Portfolio
* Introduce the concept of schema evolution and discuss the options
* choose one (I am not sure which one to choose yet)
* evolve the schema to include user and portfolio tables.
* write the associated java objects
* write the associated data access objects using JDBC
* introduce concept of integration test
* write integration tests for the DAO objects
* rework the jsps to include login, add to portfolio, display
portfolio
* all done with acceptance tests up front (this will involve
evolving an acceptance test instrumentation language that is very very
cool 🙂 )
* Deploy and demonstrate
* release
* discuss persistence frameworks.  discuss options and benefits.
mention caching.
* install hibernate
* rework to use hibernate instead of jdbc
* Discuss web frameworks and options (I am not sure if its too early
to have this discussion yet, maybe after next ‘iteration’).
* install GWT
* Rework to use GWT and discuss
* release
* extend example to allow alerts on price movements
* Rework the UI (might be better to show that straight JSP starts to
fall down at this point and then move to GWT)
* Produce an email server
* Integrate email server using JMS
* All acceptance tested and TDD’ed.
* Deploy, demonstrate and release.
* Introduce IOC containers and discuss options.
* Install spring
* Rework to use spring.
* Release.
* More steps to be added depending on what might need to be covered
for particular students.

Following that, I hope to get around to producing a follow-on series that discuss the working environment, and the way a successful team interacts in the office.  These videos will be more traditional videos, instead of screencasts.

I hope you enjoy the content, and I hope I can keep cranking it out 🙂

Keep well,

Mike