Michael's Blog

When it comes to abstractions, less can be more and the trade-offs you need to make may not be the ones you think. Let me prove it.

A short piece on styles of programming and naming things.

Sometimes I hear people saying that we should focus on writing software instead of blindly following the rules such as the ones prescribed by TDD (Test Driven Development). I agree. In real case scenarios, we should almost never blindly follow any rules. What we can do, instead, is to understand why the rules exist and if the reason behind them makes sense in the current context, consider applying them. As TDD is a set of rules that shape the software development process, it must somehow affect some qualities of the process and the software that is built. The benefits must outweigh the cost (a cost of the initial investment - learning the new skill, an ongoing opportunity cost - when only certain paths are allowed etc.). There is also the whole set of problems when TDD offers you little help. For instance, it can help you with clarifying and implementing requirements but what if you have vague or no understanding of the problem you want to solve? When we understand the costs and benefits, we can make informed decisions if the trade-off works in our favor, or if we should change the process, or maybe this time take a shortcut. It is understanding of the rules' rationale that distinguishes a fanatic from a pragmatic person. Following the rules when they make sense is a characteristic of a pragmatism (think of rules of the road and traffic lights). Consciously not following the same rules, or changing the rules that are applicable, in special circumstances (ambulance driver when using blue lights) is another characteristic of a pragmatism. However, not understanding and thus dismissing the rules, or following the rules without understanding why, have more to do with an ignorance and can be equally dangerous. Let’s leave ignorance behind us and dive into why-s then.

As promised in the previous post, it's time to show how I do TDD. It is an advanced TDD blog post in a sense that in order to appreciate it fully, one should have probably tried various approaches, be aware of some shortcomings when picking either classic or mockist approach etc. At the same time, this blog should be understood even by beginners as this is yet another way of doing TDD. Nothing prevents a person that has never tried TDD to apply this particular approach, even if they do not know the difference between above mentioned classical and mockist TDD. In fact, I think that the industry as a whole would be much better off if the first style of TDD that newcomers come across was the one presented here.

Almost every software developer at some point comes across Test Driven Development. As far as I remember I was lucky enough to try it just after I started my professional career. I remember my first interview and my first day at work. I remember how surprised and happy I was that some company trusted me enough to allow me to change their codebase - and to be rewarded for it. Thus, soon after I joined, I spent almost all my free time learning about the framework I used and about all these practices every developer should do. Proper testing, better even, Test Driven Development, was one of them.

In the previous post I created and instrumented the specification that will guide us while implementing the feature. In this post I am going to explain how it is possible that one can run such specification and check if the functionality works as expected.

Every time some part of the world that we care about (i.e. the domain around which we build the system) becomes well-defined, it is not a bad idea to write our findings down. By creating a clear rules describing business, our small world has been divided into two areas: one that complies with the newly discovered business rule and one that violates it. In order to make sure the cut is precise and the system evolves without breaking that constrains, you need a tool: a business rule test. This article shows how to run business tests efficiently.

In the previous article I presented one group of the business-facing tests I often use, which is Automated test case / use case. These tests help people understand the flow, the process and the actor’s interaction with the System Under Test. However, if you want to build a non-trivial system and you aren’t the only stakeholder, this is not enough. In order to deeply understand and validate our assumptions we need more fine grained tests. Today I’ll show you how to create such tests and be almost sure that you and other stakeholders are on the same page.

There are many types of tests. We need more than one type, because we focus on different characteristics of the system. The human readable tests (e.g. created using Gherkin language) are not an exception to the rule.

Imagine that your department is building a web application for some banking institution and the purpose of this app is to help the bank customers understand better what happens with their money when they perform operations like opening a deposit account, making a consolidation loan etc.

A few weeks ago I attended the local JUG meeting, topic of which was Specification by Example and Living Documentation. When the speaker asked if anyone had used this technique in their work, three people (from round about 30 attending) raised their hand. “10%, could be worse” he surely thought. The point was, we were all from the same company and we’d been using it because I convinced developers and management of my company to employ it. So, excluding us, no one had used it before. Why is that? People don’t need it, don’t get it or maybe haven’t heard of it?