Maybe it is just my confirmation bias, but I think the number of made-up points to win arguments get out of hand. The points get shallower and more ridiculous with every month, and it seems that there is no end in sight on how low the bar could get.
When it comes to practices and methods, there are enough real shortcomings that one could use for criticism. Instead, we can see one post after another in which people argue about things that you cannot find anywhere in the criticised subjects. Is it straw men hunting season already?
What is a straw man?
In this context, the straw man refers to the straw man fallacy which is best explained with these two quotes:
The typical straw man argument creates the illusion of having refuted or defeated an opponent’s proposition through the covert replacement of it with a different proposition (i.e., “stand up a straw man”) and the subsequent refutation of that false argument (“knock down a straw man”) instead of the opponent’s proposition.
Source: Wikipedia
A straw man fallacy occurs when someone distorts or exaggerates another person’s argument, and then attacks the distorted version of the argument instead of genuinely engaging.
Source: Excelsior
We can find these straw men in the wild, but it takes much more time to flush them out than to create them. This explains their ever-growing numbers.
Example A: TDD is (not) fundamentally wrong
The article “TDD is fundamentally wrong” claims that it is a bad idea to write all tests first and then start writing the code. That is indeed a stupid idea, but no one except the author claims that this has something to do with TDD.
Wherever we check for a definition of TDD, we find a red-green-refactor cycle that we start with a first failing test (red), implement enough code to pass this test (green) and then check if we need to improve something (refactor). From this first cycle onwards, we keep repeating that cycle by adding one more test and make sure that all tests pass.
Instead of TDD, the author suggest we should go back to the old times and write specifications and then let the developers do their work. Nice idea, but if you fail to understand a simple concept like red-green-refactor, do you really believe that a specification would be understood? I doubt it.
Example B: Stop using Page Objects
In “Stop using Page Objects and Start using App Actions” we get a long article on why application actions are much better than the Page Object pattern. The main reasoning against the Page Object is test data preparation. That is a problem we run into when we need to put an application into a known state and has nothing to do with the Page Object pattern itself.
Nowhere in the description of the Page Object pattern will we find anything that demands us to create our test data through the user interface. That is indeed time-consuming and brittle. Should you follow along the article and switch to application actions, you may end up with the exact same problem and still use too much time for test data preparation.
If we want to be generous, the author shows us why a testing strategy is important and that there are more ways to test an application than through the user interface – even when he does not realise that yet.
Since the publication of the article the title changed to “Application Actions: Use Them Instead of Page Objects“. That softened the tone a bit, but without a change in the URL it still gets shared as an argument against Page Objects.
A counter example on the test automation pyramid
When it comes to the test automation pyramid, we probably all have seen some extreme ideas that are totally off the track. Some developers even measured the initial sketch and turned it into a percentage value you must follow for the different types of tests. That is not only ridiculous, but also a costly error.
With that usual type of misunderstanding, it is a relieve to have for once some valid criticism. The post “The testing pyramid – and what comes next” by Jacqui Read is a great example of addressing the real aim of the initial approach before criticising its shortcomings. Even better, it offers us a way forward to find a better-fitting strategy for our application.
This post shows that making an argument on the real flaws of a metaphor / method / practice does not need more words to prove the points. On the contrary, if you do not have to invent flaws, you can take a shortcut and go straight from the description of the topic to its shortcomings.
Parting Thoughts
It would be great if authors would make sure that their articles have matching titles. It would be even better if they spend a bit more time to understand what they are criticising and argue about real shortcomings instead of inventing flaws to prove that they are right.
Unfortunately, that will not change in the foreseeable future. It is therefore a task for us readers to check the articles before we repost them on social media. We need to check for strawman arguments and point them out when we find them. Not only for posts where we have a different opinion, but even more so for those that confirm it. Otherwise, we will drown in a flood of misinformation and miss the important pieces that could help us to improve.