This article is part 2 of my review of the book "Fifty quick ideas to improve your tests" . I'll continue to share some of my personal highlights with you. Replace multiple steps with a higher-level step If a test executes multiple tasks in sequence that form a higher-level action, often the language and …
Review After reading "Discovery - Explore behaviour using examples" by Gáspár Nagy and Seb Rose, I picked up another book, which I bought a long time ago: "Fifty Quick Ideas to Improve Your Tests" by Gojko Adzic, David Evans, Tom Roden and Nikola Korac. Like with so many books, I find there's often a "right" …
I've just finished reading "Discovery - Explore behaviour using examples" by Gáspár Nagy and Seb Rose . It's the first in a series of books about BDD (Behavior-Driven Development). The next parts are yet to be written/published. Part of the reason to pick up this book was that I'd seen it on Twitter (that alone …
Recently I read Ouarzy's review of Jason Fried and David Heinemeier Hansson's "Remote - Office Not Required". I'd read their previous books, "Getting Real" and "Rework". They're all a joy to read. Short chapters, nice little cartoons. Just a lot of fun, and inspiring too. Not many authors make as much of an effort …
I'm working on another "multi-tenant" PHP web application project and I noticed an interesting series of events. It felt like a natural progression and by means of a bit of dangerous induction , I'm posing the hypothesis that this is how things are just bound to happen in such projects. In the beginning we start …
I find it very curious that legacy (PHP) code often has the following characteristics: Classes with the name of a central domain concept have grown too large. Methods in these classes have become very generic. Classes grow too large I think the following happened: The original developers tried to …
Exceptions - for exceptional situations? From the Domain-Driven Design movement we've learned to go somewhat back to the roots of object-oriented design. Designing domain objects is all about offering meaningful behavior and insights through a carefully designed API. We know now that domain objects with setters for …
In this series, we've discussed several topics already. We talked about persistence and time , the filesystem and randomness . The conclusion for all these areas: whenever you want to "mock" these things, you may look for a solution at the level of programming tools used (use database or filesystem abstraction …
I recently came across two interesting methods that were part of a bigger class that I had to redesign: class OrderLine { /** * @var float */ private $quantityOrdered; // ... /** * @param float $quantity */ public function processDelivery($quantity) { $this->…
Something that always bothers me: persistence (the user interface too, but that's a different topic ;)). Having objects in memory is nice, but when the application shuts down (and for PHP this is after every request-response cycle), you have to persist them somehow. By the way, I think we've all forever been annoyed …
For my new workshop - "Building Autonomous Services" - I needed to define several Docker containers/services with more or less the same setup: A PHP-FPM process for running the service's PHP code. An Nginx process for serving static and dynamic requests (using the PHP-FPM process as backend). To route …
In a previous article , we discussed "persistence" and "time" as boundary concepts that need mocking by means of dependency inversion: define your own interface, then provide an implementation for it. There were three other topics left to cover: the filesystem, the network and randomness. Mocking the filesystem …
I read this tweet: "The object-oriented version of spaghetti code is, of course, 'lasagna code'. Too many layers." - Roberto Waltman — Programming Wisdom (@CodeWisdom) February 24, 2018 Jokes taken as advice It's not the first time I'd heard of this quote. Somehow it annoys me, not just this one joke, …
More and more I've come to realize that I've been mocking less and less . The thing is, creating test doubles is a very dangerous activity . For example, what I often see is something like this: $entityManager = $this->createMock(EntityManager::class); $entityManager->expects($this->once()) …
Why code coverage for Behat? PHPUnit has built-in several options for generating code coverage data and reports. Behat doesn't. As Konstantin Kudryashov ( @everzet ) points out in an issue asking for code coverage options in Behat: Code coverage is controversial idea and code coverage for StoryBDD …
A little background: speakers don't get paid Speakers like myself don't get paid for doing a talk at a tech conference. That's why I call this work "open source". People will get a video or audio recording of the talk, including separately viewable or downloadable slides for free . The idea is, a conference costs …
This article continues where "Unary call sites and intention-revealing interfaces" ended. While reading David West's excellent book "Object Thinking", I stumbled across an interesting quote from David Parnas on the programming method that most of us use by default: The easiest way to describe the …
Call sites One of the features I love most about my IDE is the button "Find Usages". It is invaluable when improving a legacy code base. When used on a class it will show you where this class is used (as a parameter type, in an import statement, etc.). When used on a method, it will show you where this method gets …
Setting the stage: Code complexity Code complexity often gets measured by calculating the Cyclomatic Complexity per unit of code. The number can be calculated by taking all the branches of the code into consideration. Code complexity is an indicator for several things: How hard it is to understand a piece …
CQRS - not a complicated thing CQRS has some reputation issues. Mainly, people will feel that it's too complicated to apply in their current projects. It will often be considered over-engineering . I think CQRS is simply misunderstood, which is the reason many people will not choose it as a design technique. One …