eXtreme Programming Jihad

TDP - Test driven plumbing

2011-01-13T17:49:00.000+01:00

The other day I got a new washing machine installed in my house. After the first wash I noticed a small puddle of water on the floor below where the washing machine was connected to ingoing water and outgoing wastewater. I had a bug in my plumbing.

Being test driven and all I figured I first had to device a test that would indicate I had fixed the leak. I tied a piece of cloth around the joint to the ingoing water and one around the joint to for the wastewater. I ran the machine ones more and observed both cloths getting wet. I removed the cloths and tightened the joints. Tied a dry piece of cloth around each joint and ran the machine a third time. This time the cloths were dry.

I could have left the cloths there. Then I would even have had a regression test indicates which joint was leaking in case of a new leak, but I removed them, relying on the test to check on the floor for puddles.

JUnit Max Evaluation

2010-11-09T16:39:00.000+01:00

I have been using JUnit Max for a few weeks now. And feel like I am ready to do an evaluation of it.

The benefits of JUnit Max are numerous.

Tests are run faster than when you usually do when using the internal Eclipse JUnit runner, since it starts automatically upon saving a file.
More tests are run during regular development as it eventually will run all my tests for the project I am working on. When running tests manually I tend to run only a subset of tests since running tests is interrupting my coding, and I want the interruptions to be as short as possible. This makes me find unexpected side effects sooner.
JUnit gui of Eclipse have quite a few problems, specially with showing the actual fail message. JUnit max shows the message both in the problems view, and as a "compile error" with a tooltip. Which makes the actual error easier to read.
To get full use of JUnit Max you will, even more, experience the benefit of quick unit tests. Since you will be addicted to getting your test results quickly. You would not want to wait minutes for your IDE compiler, and you will eventually not want to wait for the test errors to show either.
There is no fuzz in getting it to run. If you can run your tests within Eclipse, JUnit Max can run them too.

I see only two problems, and they are rather minor.

JUnit Max adds a little bit of extra load on your development machine, if you are on the limit of what your workstation can perform this might be a problem. Upgrade your equipment!
JUnit Max costs money. In a professional environment, this should be no problem, since the costs of this software is minor compared to the cost of paying the developer to wait for tests to run.

To conclude. JUnit Max will make you work more effectively, and is worth the 100$/year it costs. Go get it!

http://junitmax.com

JUnit Max

2010-10-25T17:18:00.000+02:00

I have started to look at Kent Beck's latest creation, JUnit Max (http://www.junitmax.com). And it is looking really promising.

JUnit Max is an Eclipse plugin that run your junit test cases in the background, just as eclipse compile your code in the background. And like the compiler, JUnit Max adds those small red icons to the margin of your editor window, and also reports the test failures as problems. On my crap laptop, the load on the system is not noticeable. The results however are not as fast as the compiler responses. But still way faster than to run the usual JUnit tool in Eclipse.

I do not know yet if is worth the $100 per year fee, but I intend to find out.

Continous Deployment

2010-10-20T10:48:00.001+02:00

He might look like a punk rocker who has worn his DocMartens a few yours too many, but he is making some interesting claims.

http://saucelabs.com/blog/index.php/2009/09/continuous-deployment%E2%80%94the-video/

Watch it!

The joy of TDD

2010-10-20T07:05:00.000+02:00

During the last few weeks of work I have been working on a small web service app. The work has been done a bit on the side since I had more urgent tasks to attend to, but had some time to spare once in a while. While coding the service, which is not too complex and consists of some thousand lines of code, I worked by the motto of not adding or changing a line of code unless it helped me passing a unit test. I also set out a strategy for myself to test every detail in detail, and test that system composition was done properly, but I had no tests that exercised the whole service. Yesterday I installed the service for the first time on a web server and performed the first manual test call. It worked flawlessly.

Back in the saddle

2010-10-19T08:16:00.000+02:00

After + a year of parental leave I am back programming. Listening to
Software Engineering Radio interview with Kent Beck

The Duct tape programmer debate

2009-09-30T13:44:00.000+02:00

On Joel Spolsky's blogg, Joel On Software a few days ago there was a post called The Duct Tape Programmer. He had read a book with an interview with a former Netscape programmer called Jamie Zawinski, who he found to be an amazing programmer working in a manner that Spolsky appreciated. Spolsky gave Zawinski the title Duct Tape Programmer for his way of solving problems in stead of engineering them. He ranted about 'architecture astronauts' who make things too complicated etc. In the debate after the article the actual "Duct Tape Programmer", Jamie Zawinski, stated that Spolsky had gotten most of it wrong (that "duct tape" silliness), but anyhow the post contains some important things.

Here are my thoughts, when I trying to interpret what Joel Spolsky writes in a positive way.

The base property of a duct tape programmer is the ability do things in a simple manner. eXtreme programming has this as one of it's first rules of software design. But after that fact, the aspects of duct tape programmers that Joel Spolsky so highly admire, are hard to appreciate. Not doing unit tests will not make you deliver a working product sooner. Being a good craftsman is beneficial in programming as in any business, but when someone is going key board cow boy on a project, the mess made will still be substantial, no matter the programmers skill. Succeeding at a programming project is about cooperation, not about duct tape.

Unit testing real value functions revisited

2009-09-17T18:37:00.000+02:00

My former class mate Patrick gave me the following link
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

Apparently there are people who think quite a lot on these matters, and there are alternatives to absolute delta comparison.

Unit testing real value functions

2009-09-12T17:50:00.001+02:00

In Java, and most other programming languages, have a real number data type. These are, of course, not real numbers, but discrete ones. This provides problems when unit testing, since we often experience small truncation errors when doing repeated calculations. The assertion

assertEquals(1.0f/3.0f, fancyRealValueAlgorithm(1,3));

will often fail due to these truncation errors, even though the fancyRealValueAlgorithm really returns a value that is 1/3.

I usually resolve this by the simple alteration

assertTrue(Math.abs(1.0f/3.0f - fancyRealValueAlgorithm(1,3)) < 0.001f);

But this has a few problems. It accepts the correct things, but when the assertion fails, the output from the unit test framework is rather poor. I also need to set the limit (0.001f in the example) for each assertion. I have experimented a bit with a helper function which looks like

public void assertRealValueEquals(String message, float expected, float actual, float relativeError) {
   assertTrue(message + " expected <" + expected + "> but was <" + actual + ">", Math.abs(expected - actual) < expected * relativeError);
}

But I think there should be better ways. Just have not thought of anyone of them yet.

2009-08-30T14:22:00.001+02:00

Amen Hallelujah!

It is really long, but it contains bunches of excellent ideas.

One test case at the time

2009-08-29T23:00:00.000+02:00

When writing and implementing tests in TDD there are several different strategies on how and when to do what. I'll try to describe the two extremes.

You write all your unit tests for the behaviour/problem at hand, and implement a solution that solves them all.
You implement one unit test. Implement a solution to that particular test. Implement one more unit test, followed by a solution, and keep going until you are satisfied.

When I started working with TDD, strategy no 1 seemed like the way to go. But working that way tends to make me overwork my solutions. And since I am of the opinion that a complex solution is a bad one, at least if there are simpler solutions at hand, I have moved away from that strategy. The last months I have been working with a hybrid of the two, namely:

Write test case stubs of all the aspects of the behaviour you are working with. Example:

@Test public void testApsectA {fail("NYI");}

Implement the first test to fail when running JUnit (or whatever is the unit testing framework of the day)
Rerun JUnit, and implement next failing until done.

My idea with this strategy is that I in each test I implement only increase the complexity of the implementation as much needed for just that case.

I am starting to think that I am fooling myself though. There is a risk that while implementing one case, I am designing a solution to fit the coming cases as well. Thus being back on the first strategy. Reading
http://gojko.net/2009/02/27/thought-provoking-tdd-exercise-at-the-software-craftsmanship-conference/
which a collogue of mine sent me got me thinking about these things. And I have decided to try the idea with writing just one failing test at a time. I anticipate one problem, that I will forget requirements I used to put in test stubs before. I dunno how I will solve that one yet. I will try to keep them in my head for now, let's see where they end up.

WTF mate?

2009-08-27T17:43:00.000+02:00

Hmmm, just a few hours after writing my last post, I find this:

http://programmingsoftwareprogressive.start4all.com/2009/08/27/extreme-programming-jihad-the-pettson-problem-and-xp/

People are strange.

The Pettson Problem and XP

2009-08-27T10:11:00.002+02:00

In Sweden we have a term which roughly translates into "The Pettson Problem". It originates from a kids story where the main character, Pettson, needs to make pancakes to celebrate his cats birthday. In order to make pancakes he need flour, which he needs to buy from the store. To get to the store he needs to go by bike, but the bike has a flat tire. He has the tools to fix the tire in the tool shed, but the door is locked and the key is on the bottom of the well(!?). He has a fishing pole in the attic, which he could use to get the key out of the well, but he needs a ladder to get to the attic...

These kinds of problems arise all the time in software development. In my current project for instance, I am starting to look at the user input of recipes. In order to complete yesterdays use case completely, I at least need a web servlet of some sort and a business logics layer. To make it meaningful I would also need some sort of persistence, with some sort of database at the back.

XP offers a few hints in its rules on how to manage this, and the keys being unit testing and simplicity. But even these can be implemented in different ways:

Premade components. One common way is to design the general layers, like servlet, business logic and persistance as separate modules not related to the use cases, using generic test cases which one thinks/knows are the behaviours one wants from them.
Depth first implementation. An alternative aproach is to start with a use case, and when you discover you need any of these generic components, or need to alter them in some manner. You create it or modify as you go along.
Width first implementation. As you discover that need new functionality you create an interface for it, along with a mock that can be used for the use case currently at hand. You also create, or at least specify, a set of unit tests that tests a proper implementation of the new functionality.

Premade components are a common strategy, which feels safe and reliable. It will however rather often fail the simplicity rule, since one tends to over design generic components to solve problems that do not exist.

Depth first implementation is also rather common in real world practices. It will have a better chance of meeting the simplicity rule. It will however often lead the programmer away from the original problem quite quick, and will lead to lots of non working code until it is all finished. One more problem that might arise is that the unit tests will depend on more than just the unit it is testing. This can of course be solved by mocking the lower layer functionality, but most programmers I know, including myself, have a tendency to throw in the lower layer tests in the same tests as the upper layer tests.

With the width first approach I will get lots and lots of unsatisfied unit tests. But I will get proper motivation for all the code I write, and I will get unit tests in it proper form, where it tests units rather than whole systems. This is why I will try to maintain a width first implementation strategy in my hobby project.

Start with what is important

2009-08-26T20:55:00.003+02:00

Since I am making a site based on user generated content, the parts where the user enters content to the site is of great importance. Without thinking of any of the other parts of the site I created a simple use case.

The user enters a recipe containing an ingredient list and a description as text. The user press a post button and gets a preview of how the site has interpreted the recepie. The user goes back to the input view, and edits a few things. The user clicks post and gets the new preview. The user then chooses to save the recipe.

First thing on my mind now is to start setting up the test cases for this. But that will have to wait until tomorrow.

eXtreme Programming of one

2009-08-26T20:20:00.003+02:00

eXtreme programming is created to work with groups of people making software, and solving the issues that arrise when there are more than one chef making the soup. But several of the ideas of XP, and other agile paradigms are applicable even to projects even with only one participant.

I am starting a hobby programming project. During that project I will try to investigate some of the points I have been trying to make, along with other thoughts about software quality I have been thinking over the last years.

The project will be a user generated content site for sharing and organizing recepies. The paradigms I am planning to examine are

Various aspects of unit testing
The "one piece flow"
Working with verticals rather than layers

Since agile is the word of the day, these starting points are of course up for reconcidering. But let's start here, and see where it goes.

Agile to do the work of evil

2009-05-05T08:20:00.002+02:00

contains a bit of plump, shady jokes towards the end, but a really funny clip:

A fraction of the cost of flaws

2009-05-04T18:33:00.001+02:00

When exposing a product to a end user, one can be sure it will generate support requests. Most likely these requests needs to be acted upon, if you want to keep your users, and they will most likely be caused by a flaw in your product. Be it a communication problem, which prevents the user from understanding how your product is used, or a technical issue that prevents the user from using the product as intended, or something else. Regardless it will hopefully end up in your support organization. There it will consume time.

To look a bit into this issue I created a simple tool which I fed with 4 parameters.

An estimate of the number of users who will use the product in the future
The number of hours per week spent by support to help users suffering from the issue
A guess to whether the occurrence of the issue is proportional to a constant, linear to the number of users, quadratic to the number of users or exponential to the number of users.
A rough estimate of the time it would take to change the product to make the issue go away.

The tool plotted 2 graphs displaying the cost in work time per week and total accumulated support work. It also showed where on the accumulated time line the time supporting the issue exceeds the time it had taken to resolve it before shipping.

I created a, purely theoretical, example where I had a rather newly release product, which has a predicted user base growth of 400% in the coming year. The product has some flaws, among one of them one that rendered 3 hours of support work each week, and the work load is expected to increase proportional to the number of users. As a guess of developer time to fix the issue, I estimated 35 hours. Below you can see the result. The blue line is the accumulated work load on the support organization. The red line is the work load each week on the support organization to handle the issue. On the blue line you can see a dot where the work load on the support organization exceeds the estimated work load on the development team.

While experimenting with this tool, I quickly found out that the cost of maintaining an issue quickly grows beyond the cost of repairing the issue. One might argue that the user base growth might be unrealistic, the cost of development being higher than support per hour etc. But the key features of the graphs will remain the same.

Remember: this is only one of the costs of an issue in a product. Fixing an issue should always be top priority.

The importance of being iterative

2009-04-24T07:51:00.000+02:00

Most of us programmers like to work according to a specification. A specification that tells us what kind of problem we are solving, and what the expected results are. We usually start by making a design of the solution, then start implementing it. The implementation will contain bugs. Most programmers agree that we create bugs, and we have various ways of dealing with that fact. The design will also contain flaws, resulting in poor performance of the implementation. We tend to call these bugs as well, and try to handle them in the same way as implementation bugs. When we consider us done with the implementation of the specification we consider the feature done. Any change to the specification will be seen as a violation of contract and the large feature creep warning beacon lits.

The problem is that specifications are inherently flawed. It is extremely hard to make a good specification on first attempt.

There are several ideas that tries to deal with this problem. Extreme programming, along with may other methodologies, use iterations:

The way to improve your implementation according to design is to iterate it. This is almost always done in the process of programming. You write your tests, you write some code, you run your tests, they fail you correct the code. You improve your tests when you see flaws, you correct the code.
The way to improve your design according to the specification is to iterate it. When something that you need is not supported by the design, you change the design to support your newfound need. You will then have to go back to iterate the implementation.
The way to improve the specification is to iterate it. When you find that the specification does not deal with the problem at hand, you need to change it. Implementing the wrong thing is worse than not implementing it at all. Often you cannot see the flaws in the specifications until you have a working implementation of it to look at. When a specification has changed, you will have to iterate your design again.

Of course you can find flaws in the design before your implementation is done, and flaws in the specification before the design is done. In that case you must make the change and start over accordingly.

Failing at this will make you produce poorly working software that does not do what it needs to do for its user. It will also lower your future development velocity.

Bugs in iterative development

2009-04-04T20:13:00.000+02:00

The following article created quite a fuzz at work the other day:
[1] http://testobsessed.com/2009/03/13/handling-bugs-in-an-agile-context/

The QA team, with supporters, were upset by her saying that she though bug tracking systems were not needed, and thus should not be used. I stated that I agreed, at least in part, with her, and that made them even more upset.

I did get, at least partial, support from a my colleague Oskar (author of http://gamesartdesign.blogspot.com). We sat down and discussed it a bit and at least I drew the following conclusions:

The major problem is how we handle the development process at most companies. Oskar described it as the product owner ordered a full train set of features each sprint, where the team had to finish off all of them, with a prio order if the work load was too high. The feedback loop did only end up back at the QA or the product owner near or at the end of the sprint, where feedback was received on all the features. Resulting in loads of issues and feedback. Since all the feedback could not be acted upon at once, because there was too much feedback to be processed in parallel by the team, we have to keep track of that somewhere. In our case it was a mix of notes (mental or on piece of paper), new backlog items and bugzilla. Much of the stuff that has gone into the bug tacking in the last year of development, is still there, and will most likely be there until the project is terminated.

The solution we saw was to not build the whole train set, actually no train at all. Only one car. And to take feedback on only that car. If that feedback needs to be addressed, it should be addressed before work on the next car is even started. The rationales behind this are:

The first few guesses of how a feature should work are wrong/not good
The way to do better guesses is to analyze the old guesses and improve them
The aim is always to produce value. The value of a poorly working feature is low, or even negative.
Feedback that is not acted upon will create a debt, the lack of iterations will increase the amount of feedback that is not acted upon.

Here comes the tricky part:
A feature should not be considered done until we stop iterate on it. A feature that is not done has no bugs, since it is not even working.

Of curse there will be flaws and issues that are undiscovered when the team, QA and product owner marks a feature as done. These are bugs, and needs to be properly handled. The key in [1] is that these will not be many. Building a big apparatus to handle just a few issues is not worthwhile.

No task is too simple to not be taken seriously

2009-04-01T20:35:00.000+02:00

I have a colleague that has a standing quote he often picks up and uses:
- That cannot be more than a line of code.
He is not a computer programmer, but that attitude is often picked up by programmers as well. To some programmers, the idea that something that is just a line of code, implies that it does not require the attention that other programming does. Meaning you should not care to "details" like unit tests, design, pair programming or any other procedure you might use in more complicated situations.

This notion is sometimes (or even often) supported by project managers and other bureaucrats, which can make it even harder to resist. Doing quick fixes gives the illusion of progress, which is beneficial to all those who can take credit from it.

The downside is that you do not get all the benefits from the procedures you left out. Your code is no longer supported by the unit tests you have, which in the good case makes refactoring hard, in the worse case it creates regression flaws, and potentially adds to clutter and rotting code. You do not get the knowledge share and code review of you co programmer, since you skipped the pair programming. These things will come back and bite you, so watch out!

When not to use unit tests

2009-03-27T19:49:00.001+01:00

During my daily struggle to implement a proper working procedure at work, in this particular case, unit testing, I got the question
- When should one not use unit tests?
My gut feeling reply was never, we had a short argument about the usefulness of unit tests in various situations, and ended up in bizare margin cases, like if one should unit test ones unit tests, use unit tests when prototyping/practicing new techniques (of course you should, more than once I have seen prototype code end up in production), and my antagonist was at least sure that he would not have to worry about unit tests too much, since he was largly a GUI programmer. To remedy this I had to look up the following resources on GUI unit testing:

Test-driven GUI development with FEST - JavaWorld
Short tutorial to testing java GUIs using the FEST framework

asunit testing with flash cs3 and actionscript 3
An introduction to testing flash and action script 3 using AsUnit

NUnitForms : An NUnit extension for testing Windows Forms applications.
Gui testing for .NET. They got the concept of unit testing a bit backwards, but the methods should be usable for proper programming aswell.

I am not often faced with GUI programming in my line of work, but I hope that I can get back on this topic when I have more hands on experience.

So the question still seems open, when should I not use unit tests, I have yet to find a situation.

YAGNI

2009-03-25T07:47:00.000+01:00

Computer programmers are often immensely proud of their code, and we often brag about our fancy solutions. This is a perfect boost of ego, as well as a perfect waste of time and money.

The first rule of Extreme Programming design is Simplicity. And this is a rule one cannot under estimate.

Here is where your user stories and following user tests come into play. Every design made should be supported by a user story with accompanied unit tests. Implementation and design not explicitly supported by a user story will add to complexity, complexity will introduce more errors, increase maintenance costs, will make the code harder to read and understand and harder to refactor/rework when a better solution is found, or the requirements have changed. The benefit of making a more complex solution is that it, hopefully, adds more useful features. But since the features were not requested in the first place they will most likely not be used.

I use the following process to get on the right path:

Write the user stories together with customer
Break the user stories down into "technical testable chunks"
Write unit tests to cover the broken down user stories
Implement just enough to get a green light on the unit tests

Sure one might spin away in technical design or feature inventing orgies on item no 2 and 4, but it will only come back and bite you later on.

Unit Test Driven Development by example part 1

2009-03-11T13:41:00.000+01:00

Most programmers have heard of the concept unit tests, many of them have even tried it out. The idea to write unit tests before the actual implementation has also been presented to most programmers, and most programmers have shrugged and thought "I cannot test my code until I know how it is working". Well, most programmers are infidels.

I would claim that writing the unit tests before the implementation is the key idea behind unit tests. It will change the way you look upon the whole process of developing code, at least it did to me. It provides a natural route from feature request from the business people through out the whole life of the code. It helps you decide how complex you need to make your design.

I will here present an rather phony example, which I hope will show you the excellence of unit testing.

Unit Testing Example: The Rating Calculator
We are working on a chess game server. We have been given the assignment to calculate and store ratings at game end. The rating should be ELO with static, but configurable K and scale values.

First we start off by writing short use cases:

S = 400
K = 10
Player A has rating 1200 win
Player B has rating 1000 loose
E_A = 1/(1+10^((1000-1200)/400)) = 0.75975
E_B = 1/(1+10^((1200-1000)/400)) = 0.24025
Player A gets rating 1200+10*(1-0.75975) = 1202
Player B gets rating 1000+10*(0-0.24025) = 998
S = 400
K = 10
Player A has rating 1200 loose
Player B has rating 1000 win
E_A = 1/(1+10^((1000-1200)/400)) = 0.75975
E_B = 1/(1+10^((1200-1000)/400)) = 0.24025
Player A gets rating 1200+10*(0-0.75975) = 1192
Player B gets rating 1000+10*(1-0.24025) = 1008
... more examples with different values for K, scale, ingoing rating, winners/losers/draws and thus different resulting ratings.
When a rating calculator is called to process an unfinished game, an exception is thrown

The aim is to make each of these use cases to match one test method in the test case. Writing the use case as a comment to the test method also helps, both to remember where you put the use case, and as a sort of documentation of the test case.


public class EloRatingEndGameProcessorTest {
/**
* S = 400
* K = 10
* Player A has rating 1200 loose
* Player B has rating 1000 win
*
*  E_A = 1/(1+10^((1000-1200)/400)) = 0.75975
*  E_B = 1/(1+10^((1200-1000)/400)) = 0.24025
*
* Player A gets rating 1200+10*(0-0.75975) = 1192
* Player B gets rating 1000+10*(1-0.24025) = 1008
*/
@Test
public void testHigherRaterLooseRatingChange() throws Exception {
 Player playerA = new Player();
 Player playerB = new Player();
 Float playerAScore = 1.0f;
 Float playerBScore = 0.0f;
 Game game = new Game(playerA, playerB, playerAScore, playerBScore);
 PlayerDao playerDao = new MockPlayerDao();
 playerDao.updateRating(playerA, 1200);
 playerDao.updateRating(playerB, 1000);

 GameEndProcessor processor = new EloRatingGameEndProcessor(playerDao, 400.0f,10.0f);

 processor.process(game);

 assertEquals(1192, playerDao.getRating(playerA));
 assertEquals(1008, playerDao.getRating(playerB));
}

.
.
.

/**
 * Game has no result when rating processor is called, exception expected
 */
@Test
public void testProcessingUnfinishedGame() {
 Game game = new Game();

 PlayerDao playerDao = new MockPlayerDao();
 GameEndProcessor processor = new EloRatingGameEndProcessor(playerDao, 400.0f,10.0f);

 try {
  processor.process(game);
  fail("When processing a game with no result, we expect a GameNotFinishedException");
 } catch (GameNotFinishedException e) {
  // ok, this is expected
 }
}
}

Where

Player is the domain model player representation. *
Game is the domain model game representation. *
PlayerDao is an interface for manipulating players towards some persistent storage. The actual implementation of a PlayerDao is not under test here.
MockPlayerDao is a part of the actual test and is defined by


public class MockPlayerDao implements PlayerDao {
private Map ratings = new HashMap();
@Override
public int getRating(Player player) {
    return ratings.get(player);
}
@Override
public void updateRating(Player player, int newRating) {
    ratings.put(player, newRating);
}
}

GameEndProcessor is an interface for objects called at end of game.
GameNotFinishedException is an exception which we expect when a rating calculator is called on a game that has not ended yet.
EloRatingGameEndProcessor is the class under test, which is not written yet.

* This class is not under test, and we assert that this class is covered by other test

We continue with writing similar test cases for each use case. Expanding the interfaces as we need, but we do not implement anything in the actual source code yet!

When all use cases are covered by test cases, we run our tests and observe the results. It will fail miserably. But not to worry. Now look at the first few test failures and implement the easiest solution possible to those failures. I end up with the following implementation of EloRatingGameEndProcessor:


public class EloRatingGameEndProcessor implements GameEndProcessor {

private PlayerDao playerDao;
private float S;
private float K;
public PlayerDao getPlayerDao() {
  return playerDao;
}
public void setPlayerDao(PlayerDao playerDao) {
  this.playerDao = playerDao;
}
public float getS() {
  return S;
}
public void setS(float s) {
  S = s;
}
public float getK() {
  return K;
}
public void setK(float k) {
  K = k;
}
public EloRatingGameEndProcessor(PlayerDao playerDao, float s, float k) {
  super();
  this.playerDao = playerDao;
  S = s;
  K = k;
}

@Override
public void process(Game game) throws GameNotFinishedException {
  float ratingA = playerDao.getRating(game.getPlayerA());
  float ratingB = playerDao.getRating(game.getPlayerB());
  float EA = (float) (1.0f/(1.0f+Math.pow(10, (ratingB-ratingA)/S)));
  float EB = (float) (1.0f/(1.0f+Math.pow(10, (ratingA-ratingB)/S)));

  int newRatingA = Math.round(ratingA + K * (game.getPlayerAScore() - EA));
  int newRatingB = Math.round(ratingB + K * (game.getPlayerBScore() - EB));

  playerDao.updateRating(game.getPlayerA(), newRatingA);
  playerDao.updateRating(game.getPlayerB(), newRatingB);
}

}

We rerun the tests. If we got it all right, get a lot more uplifting results. But we still have the last test case left, so we need to do a bit more implementation.


@Override
public void process(Game game) throws GameNotFinishedException {
 if (game.getPlayerAScore() == null
   || game.getPlayerBScore() == null) {
  throw new GameNotFinishedException();
 }
...

Rerun the tests, and we observe the results. All test should now pass, and we have a rating calculator of which we can be fairly sure to state that it will update the rating according to standard ELO manners, provided the calculator is called at end game and we have a PlayerDao that stores the ratings properly. In order to know that the processor is called at end game, and the real PlayerDao implementation works, we need to write more tests...