Manage test fixtures for fast and reliable in-memory tests
Martin Fowler’s Object Mother Pattern Revisited
Many developers and testers think they are doing behaviour driven development when they use Gherkin tools, such as Cucumber, SpecFlow or BDDfy. But a tool alone does not do the trick. Why do you think the inventors of BDD stopped using Cucumber and Jbehave?
I claim that BDD is not so much about the tools, it is about a way of thinking. In this post, I will focus on one aspect of BDD which I believe the BDD community is not taking seriously enough — the initial context which is declared in one or more Given statements.
The set of one or more Given statements is the key to manage test fixtures for fast and reliable in-memory tests. More than that, my experience over the last several years shows that this is also the key to manage all levels of tests in a test pyramid. …
Practical shift-left on testing
The Startup pattern, larger units, fewer test doubles and a bit of BDD thinking.
If you have not yet read Andrew Lock’s post Should you unit-test API/MVC controllers in ASP.NET Core? then I suggest you read it without undue delay. In this post, Andrew brilliantly argues that you should not unit test controller classes.
The astute reader will notice that the title of my post is an abbreviation of the title of Andrew’s post. This is a case of less is more, since I believe that Andrew’s arguments can be stretched much more, as hinted by my shorter title.
But before I begin with a stretching exercise, let’s first note that a unit test in Andrew’s post will have a controller class as its subject under test (SUT) and all the dependencies of the controller class are substituted by test doubles, whereas an integration test will also have a controller class as a SUT, but special dependencies, specifically the ASP.NET …
When I promised to write about how to reduce friction from developers’ work day, I am sure that most expected me to focus on what non-developers ought to do in order to improve the working lives of developers.
But let’s face it, the major cause of friction, crappy legacy code, is our own fault. Developers wrote that crappy code, after all. So let’s focus on what we can do about that.
Software developers have a natural tendency to keep the hands off code that already works. …
It has been my plan for a while to start writing about all the things that make a software developer happy and active — or loyal and productive, if you prefer to see it from a manager’s perspective.
When I am asked about my opinion on the topic, I usually mention that I need the right challenges, good colleagues, a decent work/life balance — and a fair compensation.
But if you have all that and you still feel frustrated every work-day, it might be because of what I intend to write about in future blog posts — too much friction.
Friction to me is everything that gets in the way when I need to get my work done. …
About
