10 Reasons Why I’m Going to Agile Testing Days 2014

Just looked at my calendar, and it seemed that we’re only ten days away from Agile Testing Days! So here’s my rundown of the 10 top reasons to go to Agile Testing Days 2014:

10. Building a car in a day – This year, Team Wikispeed builds a car on-site with the crowd. Isn’t that cool?

9. MIATPP – This is the equivalent of a Eurovision song contest in the testing world. The crowd decides about the Most Influential Agile Testing Professional  Person this year. No committee, just the audience showing respect to knowledge.

8. Twitter – Last time, when the first keynote started, the audience was silent, but not online. The conversation continued throughout the conference. It’s like having your best friends near you discussing the sessions, live. Ideas and criticism flying by, and suddenly a formal presentation becomes a live shared experience.

7. Lean Coffee – This is one of the best meetings format I know, and having experienced (and cool) facilitators like Lisa Crispin and Janet Gregory helps too.

6. Organization – It’s their umpteenth time organizing conferences, so not surprisingly, the conference is organized meticulously. Jose, Uwe and Madeleine are always there, taking there of the smallest details, and I don’t know how, I’m sure they will even outdo themselves this year.  Being part of the organizing team of the Agile Practitioners 2015 team I know how hard it is, and I salute them.

5. The speakers – Some of the best minds in testing are there, and they are so accessible. There is no “speaker lounge”, because there’s public spaces where you just meet and talk. I’m so lucky to be included in such a great group.

4. New stuff – I’m still finding my through the testing world. Every time I’m learning something about testing I discover how big the world of testing is. So much to learn!

3. The crowd - What I’ve learned last time is the attendees are so eager to learn, open and kind, it’s easily one of the best conferences to mingle at.

2. Old friends – They may not be that old, true. I’m still in contact with some of the people I’ve met last year, and the social aspect of the conference comes alive. It’s the crowd’s affect.

1. It’s AWESOME! Nuff said.

Get your ticket and see you at Potsdam!

Legacy Code to Testable Code #6: Add Overload

This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing tests for legacy code, and how they make our life easier.

In the last post, I’ve talked about Extract Class, and that sometimes in order to do that, we might want to change the signature of a method.

Turns out adding an overload helps in other cases as well.

We used a "setter" to expose and inject internal state before. Another option is to add a controllable overload to bypass the internal state.
Let's look at this code:
public Bool isSameStreet(String newStreet) { return newStreet == this.currentAddress.getStreet(); }

In this example, we compare an external value to an internal state. As we saw before, the option we could use is add a "setter" accessor, to allow injecting the internal value from outside. Instead, we can also add an overload:

public Bool isSameStreet(String newStreet) { return isSameStreet(newStreet, this.currentAddress.getStreet()); } public Bool isSameStreet(String newStreet, String currentStreet) { return newStreet == currentStreet(); }

We do the actual comparison on the new overload. The new overload should be accessible to the test, depending on language (so it doesn't have to be completely public). In the original method, we delegate the call to the new implementation.

The new overload is more controllable. We can stop there, but if our logic code does not rely on state anymore, why not use Extract Class?

public Bool isSameStreet(String newStreet) { return StreetValidator.areEqual(newStreet, this.currentAddress.getStreet()); }

The StreetValidator class can now be controlled and tested easily.

Time to wrap up the series. So next time, in the last chapter – using dependency injection framework.

Legacy Code to Testable Code #5: Extract Class

This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing tests for legacy code, and how they make our life easier.

A few years ago I got this from Erik Talboom: "A private method is a design smell". It took me a while to fully understand it and to apply it.

There's a nice logic in there.

If at some point, we're extracting a private method from inside a public method, it probably means the public method did too much. It was long, and procedural, and probably made a number of operations. Under those circumstances, it made sense to extract some of the logic into the private method. It made sense that we could name it more clearly, as the extracted method was simpler.

It also means that the public method broke the Single Responsibility Principle. After all, we just broke it in two (at least). If that's the case, the private method we extracted contains a separate functionality from the rest of the public method.

This functionality we extracted should probably be tested. It would be easier to test, because it's smaller. If we keep it private, but called from the public method, we'd prefer not to test it directly, but through the public interface. If however we extract it to a new class, testing both will be easier, because both are simpler.

Testing and simplicity go hand in hand, and extracting into a separate class makes sense in so many cases. Too bad it's not applied often.

Here's a simple example:
public void UpdateStreet(string newStreet) { if(string.IsNullOrEmpty(street) && !street.StartsWith(" ") && !street.StartsWith("@")) { Address address = new Address(this); address.SetStreet(newStreet); } }

It makes sense to extract the validation:

public void UpdateStreet(string newStreet) { if (ValidateStreet(newStreet)) { Address address = new Address(this); address.SetStreet(newStreet); } } private bool ValidateStreet(string street) { return string.IsNullOrEmpty(street) && !street.StartsWith(" ") && !street.StartsWith("@"); }

If we keep it like that, testing the validation is problematic. Instead, we can extract the method into separate class called StreetValidator:

public void UpdateStreet(string newStreet) { if (StreetValidator.Validate(newStreet)) { Address address = new Address(this); address.SetStreet(newStreet); } }

Now we can test the Validate method, and then the original UpdateStreet method separately.

We could also expose the method as public, or make it static since it doesn't change any state. However, this may not always be the case. Sometimes in order to perform the separation, we need to actually cut the cord.

Suppose that our validation now includes comparison to the current address' street:

public void UpdateStreet(string newStreet) { if(string.IsNullOrEmpty(street) && !street.StartsWith(" ") && !street.StartsWith("@")) && currentAddress.GetStreet().CompareTo(street) == 0) { Address address = new Address(this); address.SetStreet(newStreet); } }
currentAddress is a field in our class, so it's easy to extract it into a private method:

private bool ValidateStreet(string street) { return string.IsNullOrEmpty(street) && !street.StartsWith(" ") && !street.StartsWith("@") && currentAddress.GetStreet().CompareTo(street) == 0; }
However, extracting this into separate class, requires us to pass the currentAddress as a parameter. We can do this in two steps. First, we change the signature of the method, and add a parameter with the same name as the field:

private bool ValidateStreet(string street, Address currentAddress) { return string.IsNullOrEmpty(street) && !street.StartsWith(" ") && !street.StartsWith("@") && currentAddress.GetStreet().CompareTo(street) == 0; }
Now that we “shadowed” the field, we decoupled the method from its class. The method can now be extracted to a separate class.

I find people accept extract class (if it's safe and easy) more than exposing methods, or creating accessors. The effect is the same (and the risk that someone will call it is the same), but the simplicity makes it more bearable, I guess.

Extracting a class reduces the complexity of the code and testing. Instead of the combinatorial order code paths that need testing, we lowered the test cases into linear order. Testing is not only possible, but also more probable - we are always likely to test more when the there is less to test.

That trick we did when we added the parameter? We’ll discuss it with more details next.

“The New Agile” Slides

I had a great fun presenting at the Agile Practitioners meet-up today. Good feedback, and feels like a keynote.

Here are the slides.

Legacy Code to Testable Code #4: More Accessors!

This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing tests for legacy code, and how they make our life easier. It continues the last post on accessors.

We talked about “setter” accessors as a mean to inject values. The other side of the coin is when we want to know something has happened inside our object. For example, if internal state has changed, or a non-public method was called.

In fact, this is like the "if a tree fell in the woods" question: Why do we care if internal state changed?

In legacy code, there are many cases where a class grows large and does many things. If we had separated responsibilities, the result would be possible to assert on another class. Alas, with god objects, things are a bit of a mess. When that happens, our acceptance criteria may move inside: We can either check internal state or internal method calls for its impact.

To check internal state, we can add a “getter” method. Adding a "getter" function is easy, and if it doesn't have logic (and it shouldn’t), it can expose the information without any harm done. If the refactoring tool begs you to add a "setter" you can set it to be private, so no one else uses it.

Role reversal

In a funny way, "getter" methods can reverse roles: We can use a "getter" method to inject a value by mocking it.
So in our getAccount example:
protected Bank getBank() { return new Bank(); }public void getAccount() { Bank tempBank = getBank(); ...

By mocking the getBank method we can return a mockBank (according to our tools of choice):


On the other hand, we can verify a call on a "setter" instead of exposing a value. So if our Account object has an internal state called balance, instead of exposing it and checking it after the tested operation, we can add a "setter" method, and see if it was called.


In contrast to injection, when we probe we don't want to expose an object on the stack. It's in the middle of an operation, and therefore not interesting (and hard to examine). If there's an actual case for that, we can use the "setter" method verification option.

In this example, the addMoney function calculates the interimBalance before setting the value back to currentBalance.

public void addMoney(int amount) { int interimBalance = currentBalance; interimBalance += amount; currentBalance = interimBalance; }

If we want to check the `currentBalance` before the calculation, we can modify the method to:

public void addMoney(int amount) { int interimBalance = setInterim(currentBalance); interimBalance += amount; currentBalance = interimBalance; }protected void setInterim (int balance){ return balance; }

Then in our test we can use verification as a precondition:


Adding accessors is a solution for a problem that was created before we thought about tests: The design is not modular enough and has many responsibilities. It holds information inside it, and tests (and future clients) cannot access it. If we wrote it "right" the first time, the god class would probably have been written as a set of classes. With our tests in place, we want to get to a modular design.

Tests give us the safety to change the code. So are the automated refactoring tools. We can start the separation even before our tests using the Extract Method refactoring pattern. 

We’re going to discuss it next.

Legacy Code to Testable Code #3: Adding Setter Accessors

This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing tests for legacy code, and how they make our life easier.
Irish Setter. He's a go-getter.
Irish Setter. He's a go-getter.

Adding accessors to private state data is an admission that either our design is wrong, or that we're adding the accessors purely for testing. If that state was private before, how come are we exposing it? And if so, maybe tests are not the only clients of this data.

We need an accessor in two cases:
  • When we need to inject values that are otherwise hard to inject
  • When we need to probe the internal state to understand the impact of our operation
In both cases, we're adding functions that were not needed before. Meaning, the caller did not need to either inject or probe the data. Now our tests, another client, demand an additional entry point. In this post, I’ll concentrate on the Set accessors for injecting values.

Injecting values

If we have other methods, we might not need an accessor. For example, we have a private field that's initialized in the constructor:

public Account(Bank bank) { this.bank = bank; ...

If we pass the new bank value as a parameter, we can set it in our tests easily to whatever we need. However, if the constructor looks like this:

public Account() { this.bank = new Bank(); ...

The seam for inserting our bank is no longer there, and we need another way to inject it. In another case, the new bank can come from an external source:

public Account() { this.bank = BankFactory.getBank(); ...

In both of these cases, we can mock the creation or the static call with power tools. If we can't use those, we can introduce a "setter" method. This "setter" can be public or at least accessible to our test.

public setBank(Bank bank) { this.bank = bank; }

When we call this method, it overrides the value that the constructor initialized. This doesn't work if our constructor already did something with the original value. Usually it's not a problem, because we're testing code in another method, so whatever the constructor did, the tested method will be under our influence. In other cases, we can mock the constructor using partial-mocking for eliminating code that runs in the constructor, or use power tools to mock the factory method.

From here it gets complicated. What if our `bank` is static? Consider a private static singleton:

private static Bank theBank = new Bank():
Once initialized, it cannot be replaced through regular means. If our test calls for it, replacing it can be easier by injecting our own mockBank. So we can add a static "setter":

public static void setBank(Bank bank) { theBank = bank; }

As before adding an external "setter" is a risk: What if someone else decides to call it? We can reduce accessibility, but the risk is still there.

In both former cases, we could store the overriding mockBank. It maybe that the value is not stored anywhere, only created on the stack, in the tested method:

public void getAccount() { Bank tempBank = new Bank(); ...

Here, we cannot access tempBank, because it's on the stack. In this case, we can do a bit of refactoring in order to allow injection. We'll first extract the creation into a private method called getBank:

private Bank getBank() { return new Bank(); } public void getAccount() { Bank tempBank = getBank(); ...

Using refactoring tools, we can reuse this method for every creation. We can then introduce a field and a "setter", and modify the getAccount method:

private Bank bank = Null; public void setBank(Bank bank) { this.bank = bank; } private Bank getBank() { if (this.bank == Null) return new Bank(); else return this.bank; }

Using this method we skip mocking (and reduce coupling) at the expense of design changes. We can't escape trade-offs.

There's a final option for injecting values, if the language supports it: Reflection.  If we use reflection in the test, there is no need for modification in the tested code. However, tests using reflection are as fragile as mocking tests, sometime even more so. Reflection access is fragile, and not refactorable. Therefore, this method should be considered last in the solutions offered.

That’s it for now. Next time we’ll continue the discussion about accessors with “getters”.

Image source: http://en.wikipedia.org/wiki/Setter

Legacy Code To Testable Code #2: Extract Method

This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing tests for legacy code, and how they make our life easier.

As with renaming, extracting a method helps us understand the code better. If you find it easy to name the method, it makes sense. Otherwise, you just enclosed code that does a lot of things. It can be useful sometimes, although not as extracting small methods that make sense.

Extracting a method also introduces a seam. This method can now be mocked, and can now affect the code as it being tested. One of the tricks when not using power-tools is wrapping a static method with an instance method.

In our Person class, we have the GetZipCode method:
public class Person { String street; public String getZipCode() { Directory directory = Directory.getInstance(); return directory.getZipCodeFromStreet(street); } }

The Directory.getInstance() method is static. If we extract it to a getDirectory method (in the Person class) and make this method accessible, we now can mock it.

public class Person { String street; public String getZipCode() { Directory directory = getDirectory(); return directory.getZipCodeFromStreet(street); } protected Directory getDirectory() { return Directory.getInstance(); } }

While it's now very easy to mock the getDirectory method using Mockito, it was also easy to mock the Directory.getInstance if we used PowerMockito. Is there an additional reason to introduce a new method?

If it’s just for the sake of testing - there's no need to do the extraction. Sometimes, however mocking things with power-tools is not easy. Problems appearing in static constructors may require more handling on the test side. It may be easier to wrap in a separate method.

There are times when extracting helps us regardless of the mocking tool. We can use method extraction to simplify the test, even before we've written it. It's simpler and safer to mock one method, rather than 3 calls.

If our getZipCode method looked like this:

public String getZipCode() { Address address = new Address(); address.setStreet(street); address.setCountry(country); address.setState(state); address.setCity(city); Directory directory = Directory.getInstance(address); return directory.GetZipCode(); }

Even with power-tools, faking the Address instance and setting the rest of the behavior settings just for retrieving the directory is quite a lot of work, which means a longer test with a long setup. If we extract a getDirectoryFromAddress method:

public String getZipCode() { Directory directory = getDirectoryFromAddress(); return directory.GetZipCode(); }

We get more readable code, and we'll need to mock only one line.

While extracting has its up side, making a method a seam comes with the baggage. If the method is private, and we use power tools to mock it, coupling between test and code is increased. If we make it public, someone can call it. If it's protected, a derived class can call it. Changes for testability is a change of design, for better or worse.

Up next: Creating accessors.

Image source:http://commons.wikimedia.org/wiki/File:Dentist_extracting_tooth..JPG
Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More