Change the binary path for a Windows service

Do you need to change the path to a binary a Windows sevice is executing? Maybe you want to change the location of where a service is installed?

Teaching – the difference between a lecture and a conversation

There is a big difference when teaching a large group and teaching a small group. I recently had the pleasure of teaching the same material in a few different scenarios. One of them with a large audience of about 70 participants. It took me approximately 2.5 hours to go through all slides and coding an example. Two other scenarios was with small groups with less than 10 participants. The exact same material took a little over a little over 3 hours to complete.

Embrace change or embrace uncertainty

Kent Beck wrote a very nice book eXtreme programming explained with the subtitle “Embrace change”. But what he really want to embrace is uncertainty. What is uncertainty? It is those things that will happen but you are uncertain of. Possibly so uncertain that you haven’t even thought about them in a risk analysis. It is the very nature of uncertain things, you don’t think they ever will occur and can therefore not even think they might happen. They will therefore never turn up in a risk analysis.

This is what Agile and XP is all about. Handling uncertainty. Instead of taking long leaps, you frequently stop, inspect and adapt. You always tries to have the shortest possible feedback loop. You deliver working software and evaluate if it brings the values you expected it would bring. Then decide what to deliver next.

Inspecting and adapting doesn’t mean that you shouldn’t think and try to come up with reasonable risks that you want to prepare for. But at the same time, it doesn’t mean that you should stop and think forever about the risks and never deliver anything.

So embrace the uncertainty and make sure that the way you work support you as much as possible.

Resources

• eXtreme programming explained
• Thomas Sundberg – The author

Maven – the simplest possible introduction?

Maven is a build tool for Java. You define a project with Maven, build and test your product.

Usually you hate Maven or you love it. Before you have understood how things work, you usually hate it. If you persist, then there is a chance that you will like it.

I have met many developers that claim that Maven is either “To complicated” or “Impossible to understand”.

I have even been asked “Don’t you feel dirty using Maven?” during a session at an Agile conference. My answer was “No, why should I feel dirty for using a good tool?” This question and an opinion stated at another conference triggered me to write this. I aim to show you how Maven can solve some problems, using baby steps and starting from the simplest possible solution that could work. My goal is to write an easy to understand getting started guide. If you think I take a too large step somewhere on the way, please give feedback and tell me where I take a large step. If you think my steps are to small, then you probably already know enough about Maven so you don’t need this introduction.

Take control of your time

Testing is all about verifying that something works as expected. What are the challenges then? There are many, one very obvious is to actually know how it should work. Another challenge is to isolate the system under test so that it is possible to know what is tested and determine if that specific part works as expected.

Test coverage – friend or foe?

Measuring the test coverage is something many people think is a good idea. But is it a good idea? It depends on the quality of the tests. Test coverage may be a good measurement if the tests are good. But suppose that we have a high degree of test coverage and bad tests?

I will show two examples of how to get a 100% test coverage using Cobertura. They will be based on a set of good tests and a set of bad tests.

How is test coverage calculated?

Test coverage is calculated by recording which lines of code that has been executed. If the code has been executed through a test in a testing framework then we have calculated the test coverage.

The calculation is done using these steps:

• Start with instrumenting compiled code
• Execute the instrumented code
• Each execution of a line is recorded in a log
• Combining this execution log with the source code enables us to calculate how many lines out of the total number of lines that has been executed

We will be able to say that 47% of the lines in the source code has been executed. If the execution is done through test code, this will give us a measurement of the test coverage.

Cucumber-JVM – not just for testing GUIs

Cucumber is a tool that supports Behaviour Driven Development, BDD. A lot of people think that the only place where a system has behaviour is in the user interface and especially in the graphical user interface. As a developer I know that this is not the case. All systems have behaviour at different places and different levels.

I will show an example of how a system can be developed using its desired behaviour and start from a non graphical point. I will work from the model down to the database and when I’m happy with the logical behaviour I will add a graphical user interface on top of it. I will actually add a few different interfaces; two web-based, one swing and two different types of web services. The result will be an example of Model View Controller, MVC, developed using BDD.

An important point when I add the GUIs or web services is that I will not change the desired behaviour. I will only change how the behaviour is verified. This is one way of showing you that Cucumber and BDD is not about testing GUIs. It is about systems behaviour.

Building the model

Previous – Introduction

The feature I will start with looks like this:

src/test/resources/se/waymark/rentit/Rent.feature

Feature: Rental cars should be possible to rent to gain revenue to the rental company.

  As an owner of a car rental company
  I want to make cars available for renting
  So I can make money

  Scenario: Find and rent a car
    Given there are 18 cars available for rental
    When I rent one
    Then there will only be 17 cars available for rental

It consists of three parts:

• Given – the preconditions of the system under test. The setup of the systems state if you want. In this case make 18 compact cars available for rental in the system.
• When – the actual change of the system. Transforming it from the initial state to the final state. Rent one car.
• Then – the expected final state of the system. The verification that the state change was the desired change. After one car is rented, there should only be 17 left to rent.

A JSF web application

Previous – Building the model

Many modern applications are built as web applications. The benefits are obvious, you don’t need to package your software in shrink-wrap and send it to your customers. Upgrading is easy, you have to upgrade the server you host the system on and that’s it.

The first user interface I will add to the rental system will therefore be a web GUI. It will be the simplest possible solution and the goal is not to build a fancy web app. The goal is to show how Cucumber can control a tool like Selenium WebDriver to assert the behaviour of the web application.

A Wicket web application

Previous – A JSF web application

A wicket application is yet another web application. I divide the project in two parts as earlier. The only large difference is the support class that will connect to the system under test. It has been adapted for another web application.