All computer systems are equal, but some systems are more equal than others. At least on a high level.
They are all subject to these actions:
- Enter data
- Apply business rules – morph the data
- Persist
- Retrieve the transformed data
October 13, 2012
All computer systems are equal
September 28, 2012
Test drive an implementation using an Executable Specification – revisited
An example is perhaps the best way to describe something. Concrete examples are easier to understand than abstract descriptions.
I will show how Cucumber-JVM can be used to specify an example and how the example can be connected to the system under test, SUT. The example can then be executed using any IDE or using Maven.
June 15, 2012
Pair Programing
How do you solve a problem best? In your solitude alone or in a group? I know that I solve problems better in a group. The group has to be small so you don’t get disturbed. But it has to be large enough so a discussion can occur.
Programing is not about writing text fast. Typing is never the bottleneck when programming. The bottleneck is problem solving and solving the right problem.
Pair programming is about two persons that solve a problem together. Problem solving in a group tend to result in better solutions. Different people see a problem from different angles. The result is usually better than a solution that one person came up with.
March 7, 2012
What is a good test?
A colleague asked that question the other day. What is a good test? It is a really difficult question to answer. There are a number of properties that hold true for a good test. I will list some of them and discuss why I think they are important. Others may think that the order of importance is different or that other properties are more important then those that I list.
I will show some examples using Java and JUnit of what I think are bad tests and how they can be refactored to something better.
Tests are automated in my world. I always try to avoid manually testing. The main reason for this is that manual testing is slow and hard to repeat arbitrary many times. Therefore, test should be read as automated test in for the rest of this text.
December 30, 2011
How many train wrecks are lurking in your code?
Train accidents are mostly considered to be bad things. People tend to get hurt when trains have accidents. Never the less, it is not so uncommon with train wrecks in software development.
Train wreck code is code that calls a method on the return value of another method call. This chain can be very long if a value is excavated deep down in a object graph.
October 18, 2011
Testing a web application with Selenium 2
Selenium a great tool for testing web applications. The current version, Selenium 2, is a merge between Selenium and WebDriver. I will walk you through an example where we test a web site using Selenium in a few different ways. This is the same example as I demonstrated at Scandev on tour in Stockholm 18 October 2011.
September 16, 2011
Test drive an implementation using an Executable Specification
An example is perhaps the best way to describe something. Concrete examples are easier to understand then abstract descriptions.
I will show how Cucumber-JVM can be used to specify an example and how the example can be connected to the system under test, SUT. The example can then be executed using any IDE or using Maven.
July 28, 2011
Do not return null
Using your IDE to automatically create methods for you maybe a disaster waiting to happen.
Magic numbers
The other day a colleague asked me, what is a magic number? He had noticed that one of the things our Sonar was complaining about was Magic numbers. I got a great teaching moment and told him my view of Magic numbers.
Magic numbers are any numbers in the source code that just appears without any explanation.
April 24, 2011
FEST Assert – a fluent interface for assertions
Hamcrest is a great framework for assertThat and it is bundled with JUnit. It is getting some competition from another framework, the FEST assertThat framework. The idea behind FEST is to use a fluent interface. This means that you can use your development environments code completion features to build your asserts. Its main goal is to improve test code readability and make maintenance of tests easier.
