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.

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.

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.

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

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.