Session 11

Project Development, Day 2

810:188
Agile Software Development

Daily Stand-Up Meeting

We go around the room and report:

• What did you do yesterday?
• What do you plan to do today?
• What is in your way?

Everyone reported on the progress they made last time. There were no obstacles to report. (Expect that to change.)

Quick Discussion: Continuous Integration

What's the issue?

Some comments on continuous integration:

• Code should be self-testing. This does not require doing TDD, only that we have good test coverage of our code and that the tests are automated.
• Fowler outlines the key steps in practicing continuous integration. One practice that we need to adopt: run all tests before checking any code into the mainline.

How can rake help us?

For now, rake could help us run all our tests upon integration.

• Currently, testing by hand requires finding and running all of our Test::Unit files.

           > ruby Account_Tests.rb 
           > ruby GeneralJournalTests.rb 
           > ruby TestAccountInitialization.rb
  



• We can make this process semi-automated by creating a rakefile with a task that executes all of our test. [...look at rakefile...] We still have to remember to run our tests, but now the process is aided by rak.

           > rake test
  



• We can fully automate this process by configuring svn to rake our tests -- or so a complete build -- on every commit. This requires adding a 'hook' to svn, which requires admin privileges on the svn server, student. [We are looking into this.]

Quick Discussion: Team Standards

Last time, we ran into a need for...

team standards, whether for code (say, common naming conventions for factory methods) or for design (say, how the program should behave when it is unable to create an object in a particular situation).

Looking at the current state of our repository, I see a need for another standard convention: the naming of our Test::Unit files. Running all of the tests by hand is currently difficult because it is hard to find the test files! It is hard to tell system code apart from test code.

The common convention is ClassnameTest.rb. I can imagine the team adopting some other convention, such as TestClassname.rb. (Can you think of any specific advantages of one over the other?)

Another advantage of following some convention is that we will then be able to automate the finding of test files. This is similar to why we prefix the names of Test::Unit::Case test methods with test. It enables the test framework to find and execute all of our test methods without us having to enumerate them anywhere. If the names of all our test files follow a simple convention, we should be able to write a rake script that detects and executes all of our test files without us having to enumerate them anywhere!

One of the pairs should make its first task today to be to bring our test files into compliance with the standard we decide on... now.

Again, They're Off!

Everyone: pair off, check out a clean copy of the project repository:

    svn checkout https://student.cs.uni.edu/svn/810188-May10

... grab a story, and write a test.

A few lessons learned or to be learned:

• Our story about recording transactions in specialty journals is way too big. It probably needs to be one story per specialty journal that the customer desires. Perhaps we need only split it into two stories: one for the first journal, and one for producing specialty journals automatically based one what we learn from implementing the first. Let's see what the team learns from today's work.


• The story collision issue discussed last time continues to occur. What can we learn from our experiences with these situations that we can use to improve what we do and how we do it?


• Today, you worked more than half the class period without your customer. How did that affect what you did, how you did it, or how well you did it?

Keep in mind that each team member should be doing a couple of units of work on the system out of class every day.

Wrap Up

• Homework. Send me a short e-mail with answers to the questions in the last two bullets of the preceding section, along with anything else you noticed today.


• Reading. Be sur you understand Fowler's Continuous Integration paper, and then try to understand as much about Rake as you can, given your current level of software development experience. Fowler's Using the Rake Build Language is perhaps a bit advanced for many of you.


• Programming. Keep learning Ruby, especially any language features you encountered today but didn't understand well. You may also work on the team project but only with a partner. We will continue to do pair programming for all team code.