Thursday, April 28, 2016

I'm not the first person to have this problem

I'm going to try to post once a week to document what I'm doing with contract and anything else that happens to cross my mind ...... 

And because these blog posts look better with at least one photo.

Surely I'm not the first person to have this problem ???

This question has saved me more wasted effort and wheel re-inventing than any other. The ability to sit back, look at a problem and acknowledge the fact that people have come before us and that there is something to be learned from them. There's no place were this is truer than the software development industry. So, the next time you go to put finger to keyboard say to yourself "Am I the first person to have this problem??"  Often the answer is no. There's something we can reuse to make our lives a little easier. Then we can concentrate on the truly cool stuff we can build. 

How did we end up like this?? I can only speak for myself. I blame my college education. I'm not speaking ill of the Dublin Institute of Technology, they did a fantastic job of educating me. In college we were taught to do everything from scratch. You need something sorted, you wrote quick sort yourself, arrays we're used for everything and an IDE was the work of the devil. You leave college and you're presented with Java Collections and wonder why you were never taught about them. But that old mentality of 'Do everything yourself' was still there. So every chance you get. Ask yourself that one simple question and see where it leads you. 

Hows contract going?
Grand, ticking over nicely. I spent the weekend hardening my Jenkins pipeline to maven central (it was a little flaky, still is, the kvServer tests are a nightmare to run well), added the ability to handle current timestamps (it was an early feature request for servers that return the time a request was processed at). Allowing for bodies to be specified in native json as opposed to escaped strings. 

I'm going to aim to release once a week, lets see how that goes. 

Thursday, April 21, 2016

Introducing, Contract 0.0.1

Two years ago, I started asking myself that question "surely, I'm not the first person to have had this problem". I was working on a green field project and was looking for a better way to test the interaction between services that communicate over HTTP. I ended up using a project called Wiremock to replace one of the systems for testing and everything worked quite well. But it wasn't perfect.

A year ago, I found myself in the same position again. This time I stumbled across consumer driven contracts and pact-jvm. We were developing the server at the time and the client was being developed in another department we couldn't dictate their test approach. We build our own contract driven frame work on top of Wiremock and again, it worked quite well. But it wasn't perfect.

I started working on 'Contract' a few months ago. Replacing Wiremock with a embedded tomcat and using the lessons learned from both stalled attempts to build this tool. Contract will provide a contract-server that will respond based on the supplied contracts to a client system and a contract-client that will send requests and validate the responses from a server under development. Combine the two and you've got test symmetry.

After battling with Jenkins for the last 2 days, 'Contract' is now up in maven central. What it currently lacks in features, it makes up for in simplicity.


And now that the basics are in place, its feature time. Watch this spot for more features!!!

Wednesday, April 13, 2016

Testing the test tool

Going back to working on my HTTP contract testing tool, I've basically realized for the most part that I'm done!! Well, the minimal viable version is done. No bells and whistles just yet. So, why the lack of confidence in releasing it?

I've nothing in the region of acceptance tests. Over the last couple of years I've gotten exceedingly comfortable with this safety net to catch my numerous fuck-ups. My project is unit tested to an inch of its life. I'm comfortable that my coverage of 95% is exactly that, and worthwhile at the same time (maybe i'll add some mutation testing at some stage to see how accurate that 95% actually is).

In order to give myself that safety net and feel comfortable releasing my project I went about testing a test tool. Something I've never done before. A bit of background. Contract is a JVM testing tool designed to replace mocks and test clients in HTTP client server tests and provide identical yet separate test suites for both.

If I were testing a web-app, the first port of call would be to try to think like a user and use the system. Why not the same for a test library. I gave myself 2 users. A client and a server. I designed the simplest server I could think of, a server side map, send a key value pair it saves it for later retrieval. Paired with a client to provide java based access to the same server. I wrote the contracts to define expected behaviours. To follow my own best practices, I put the contracts in a third location so they were accessible to both.

The results: things didn't work exactly as i'd expected. My confident lack of confidence paid off again. Time to fix me some bugs!!!!

What went wrong exactly: when I left out the 'Content-Type' header the server responded with a 415. In the contract that defines this behaviour I left the body blank, I wasn't really concerned with what the body sent back, its usually garbage anyway. NullPointerException, bodies in the response of a contract are mandatory apparently.

Some links:
Contract: https://github.com/harmingcola/contract/
KvServer: https://github.com/harmingcola/kvServer
KvClient: https://github.com/harmingcola/kvClient
KvContracts: https://github.com/harmingcola/kvContracts
Docs: http://harmingcola.github.io/contract/index.html