Monday, 13 April 2015

Cool URI's Don't Change

I switched domains back in June 2013. This was out of my control. A lot of links were lost despite an attempt to backlink in order to keep the traffic from the old links and new links crossing over. The previous domain also broke content without consideration, there are links around that simply point to nothing.

To compound the issue I switched this blogs platform back in June 2014. This was much overdue, but an issue fully in my control. This yet again, broke links despite being for the better. My link management has been poor and given how annoyed I become at other sites breaking links, it's time to make a stand.

A recent example was when I was on holiday with a limited wifi connection of an evening. A couple of users on Twitter wanted to share some of my content, but the link was broken. After some delay and flip flopping I was finally able to share the post they were after. I am extremely happy that Paul thought of a blog post I wrote, so the fact that he was unable to share it was embarrassing.

An old mentor of mine introduced me to Cool URI's early on in my career and highlighted the importance of choosing a good URI scheme. From this post onwards no links to my content both past and future will break, despite hosting or platform choices. I've introduced an automated process to check each post when the blog is backed up, to ensure this never happens again.

The lesson here is simple. If you publish content on a site under your control, it's your duty to ensure you handle breaking changes.

I debated the use of URL or URI for this post initially. For future reference, URI's identify, URL's identify and locate.

Thursday, 9 April 2015

DRY vs DAMP in Tests

In the previous post I mentioned that duplication in tests is not always bad. Sometimes duplication becomes a problem. Tests can become large or virtually identically excluding a few lines. Changes to these tests can take a while and increase the maintenance overhead. At this point, DRY violations need to be resolved.


Test Helpers

A common solution is to extract common functionality into setup methods or other helper utilities. While this will remove and reduce duplication this can make tests a bit harder to read as the test is now split amongst unrelated components. There is a limit to how useful such extractions can help as each test may need to do something slightly differently.

DAMP - Descriptive and Meaningful Phrases

Descriptive and Meaningful Phrases is the alter ego of DRY. DAMP tests often use the builder pattern to construct the System Under Test. This allows calls to be chained in a fluent API style, similar to the Page Object Pattern. Internally the implementation will still use literals or value objects, but each test can provide just the differences it needs in order to execute. The key point regardless of how DAMP tests are implemented is to favor readability over anything else, while still eliminating duplication where possible.

The example shows a typical arrange aspect of a test written in the DAMP style. The end result of this builder is we will have the ability to now act and assert against the result - a controller instance. If further tests were required we could use the same setup but simply provide different order dates for example. Additionally we could add or remove further chained calls. Behind the scenes the implementation of these builders is straightforward.

I tend to introduce this pattern after the third time of seeing duplication between tests. There is a bit of an overhead otherwise, the builder itself requires implementation and careful construction. Once you go past three tests the overhead pays itself off by allowing you to rapidly add new tests and make large, structural changes.

Beware the builders becoming too big or complex. If this starts to happen you may wish to refactor as there may be missing abstractions in your design. DAMP tests have numerous advantages, but they should be applied where required rather than for every scenario. Tests for objects that are lower in the dependency graph tend to fit into the more traditional testing patterns, while higher up your stack DAMP tests can prove useful.

Wednesday, 1 April 2015

Randomly Generated Values in Tests

The use of randomly generated test data seems like a good thing at first glance. Having worked with several teams that have used this concept I generally discourage the practice. Consider a simple method that joins together two strings. A test using random values may look like this.


Harder to Read

While this is a toy example to demonstrate the problem, in more realistic scenarios the lack of literal values harms the readability of the tests. It is worth noting the lack of literals causes more lines of code as anything that has importance needs to be stored in a variable or field. My biggest concern is when assertions start to become complicated or even worse, duplicate production code in order to pass. If we wish to treat tests as examples, this is pretty poor.

Edge Cases

Generating a random string seems easy enough. Overtime the edge cases in question start to ramp up. You have whitespace, special characters, new lines, numbers and much more to worry about if you wish to do this properly. The code to actually generate random values is often shared via inheritance or composition, this makes changes tricky and dangerous as you can inadvertently change more than one test when modifying this common code. If the two inputs need to be different then you could potentially generate the same string each time, leading to flaky tests if you're not careful.

Psuedo Random

The random aspect of these tests can confuse developers. In the example above, there is only ever one value for each variable. In other words this test can run many times locally and pass, but fail when executed elsewhere. There may be a subtle bug that is only found after the code is declared complete. This issue often causes failures in the build, at which developers declare "it's just a random failure" before re-triggering the build because a value may be invalid for a specific scenario.

Date/Times can be Tricky

Date/Times are hard enough as it is. Trying to randomly generate these is not worth the hassle.


My recommendation is to rely on literal values or value objects where possible, these make the test much more readable and act like an example or specification. Additionally their use allows the inline variable refactor to take place, meaning shorter, conciser tests.

Test Cases/Parameterized Tests

If you wish to test similar scenarios in one go then test cases can help. This is usually the case when you cannot name a test easily because the functionality is the same as an existing test.


The assumption that randomly generated tests catch bugs and cover more ground is wrong. If you really do discover a bug after manual testing or on a live system just write a new test exposing that bug and fix it. Thinking you cover more scenarios by using random values is false.

Property Based Testing

I cannot comment on Property Based Testing fully, but this is certainly an interesting area and does not suffer from the issues above. Worth looking into.


This solution certainly violates DRY. There is clear duplication. If this was production code I would remove it, however for tests my stance for a long time has been to allow this duplication to remain. Readability and expressiveness is much more important. There are valid times when duplication between tests is a bad thing. While this simple example doesn't suffer from this problem I will expand on how to keep your tests expressive but DRY in a future post.

Wednesday, 18 March 2015

Remote Meetings - Balancing the Act

Meetings are hard when some team members are remote and are physically based in the same location.

It is easy for the remote user to feel second class in terms of the meeting. Remote workers can find it hard to add to the meeting without interrupting or getting left behind.

One practice to balance the process of remote meeting is to ensure that if one or more parties are remote, all participants remote into meeting.


  • Levels playing field - everyone should have equal opportunity to contribute.
  • Removes lag - everyone has the same experience of time/delay.
  • Includes online benefits such as message logs, sharing of screen.
  • Comfort of own desk/environment.

This idea was taken from Stack Exchange's post detailing why they still believe in remote working.

Wednesday, 11 March 2015

Dependency Elimination Principle

This is the third, and final part of my series on abstractions.

I've wrote about what good dependencies are before, and the benefits if you can limit and remove them where possible.

You can take this idea further though, by applying concepts from functional programming such as "depend on values rather than dependencies".

A wise colleague started me down this path of passing values, rather than dependencies on collaborators after we repeatedly found ourselves depending on implementation details. This meant our high level domain logic was tightly coupled to low level implementation details.

Brian Geihsler reminded me of this concept with an excellent demonstration of this in practice and has allowed me to put a name to this practice.

Additionally J.B. Rainsberger's example is with a virtual clock, another common dependency we often need. In this case, ask for the time, not how you get the time. The example also highlights another common problem with conventions when using a framework or library.

Here we can handle commands but only those that match the signature of taking a single command, and returning no response. In order to apply the Dependency Elimination Principle (DEP) and remove the clock wrapper we can introduce an overload. Our tests will be expressed using the overload, while the production code will make use of the standard method. If the class in question has a relevant set of interfaces, the overload would be omitted from this to ensure that consumers have a clean, focused API to consume.

When the DEP is applied to other dependencies such as configuration details, flexibility is achieved by the ability to provide these values from any source. As a side effect, coupling has been reduced, while also removing an unnecessary abstraction from the codebase.

Try to apply the DEP where possible. Remove as many dependencies as possible for flexible, maintainable code. Not all dependencies can be eliminated, but unless the dependency is a valid abstraction it may be worth considering removing or reducing use.