The other day I had to figure out a way to compare two different web services to see whether a subset of their output are equal or not. One of these services (let’s call it the legacy service) is capable of emitting XML as a response, while the other one (a completely new service that is intended to be a replacement for the legacy code) uses JSON. Unfortunately, the output of these two are only similar in a conceptual way; their structure differs a lot, they use very different ways of structuring data. I checked out some common frameworks for testing web services, and though all of them were useful for parts of my task, they proved to be hard to use for my complete work. Of course, all these frameworks all all too general purpose, while my problem is, I guess, not that of a common use case. At this time I started experimenting with REST Assured – a framework that finally saved me a lot of time and effort. In the below short post I will describe how easy it was to get my job done in a relatively short time, with this cool framework.
Once I heard a talk, where the presenter asked the audience how would they write hard to test code on purpose. People in the room were a bit shocked, as nobody would write bad code intentionally. As far as I remember, they couldn’t even come up with very good answers to this question.
Of course, the purpose of this question was not to educate people on how to code in a way that makes their colleagues’ lives harder. Knowing what makes code hard to test can help avoiding some serious problems. Here’s my list of answers to the above poll (of course it’s really subjective, almost everyone has a different set of smells that they hate most).
For the past 2+ years, I’ve interviewed more than 150 people for different Java positions, from junior to senior+ levels. During these technical discussions, I’ve observed a number of strange patterns repeating over and over again. Some of these are really counter-intuitive, maybe I’ll be talking about these in a different post.
All these interviews were really, really different, but one thing is constant: people get scared once they have to solve a programming puzzle at the whiteboard. I remember how I hated these kinds of tests when I applied to my current company. My reaction was not any different from most of the candidates’ I talk with. The whole thing went like this: I told the interviewer how I hated these exercises, I mentioned how the problems were not realistic and finally, at the end of the exercise I complained about how I missed good old JUnit. As I mentioned, nowadays’ candidates are not very different and I usually understand them. I really thought the puzzle part had to be done to torture people, who already happen to be freaked out as hell, with their pulse above 180, and can’t even stop sweating.