When you run tests in a random class and method order, which results in them failing, you have demonstrated test pollution. This is usually the result of sloppy tests that don’t clean up after themselves. Taking the time to understand the failures can help point you towards the root cause of pollution. Recipients of pollution are either Beneficiaries or Innocent Bystanders. Beneficiaries Beneficiaries are those tests that originally took advantage of test pollution, baking it into the assumptions used to write the test.

The ability to randomize the order of tests has always been a useful tool for diagnosing flaky tests. However, until JUnit 5.8.0, developers were only able to randomize the order of methods within a test class using MethodOrder$Random. With the addition of MethodOrderer$ClassOrderer, it is now possible to randomize the test classes too. For the rest of this article, I will walk you through how to enable test classes and methods to run in a random order with the following steps:

As a developer on a scrum team, you have likely watched helplessly as the pressure from stakeholders mounts. Despite each sprint containing a multi-hour planning meeting, and producing a Gantt or Burn-down charts, your leaders never seem to be satisfied with the progress. Situations like the one described are often due to a lack of trust. Trust is not built only with charts and graphs, but by making work visible to management.

It is the kind of code that makes you squint. It could be that stray business logic in a controller, a view that queries the database, or even two intertwined features that change for different reasons. I am talking about code that is hard to read. Cryptic code slows everything down. It is the thing that makes a seemingly simple feature take weeks. Though we all can recognize unreadable code, it seems to keep showing up in our code-bases.

So I would have considered this crazy a few years ago, but I wrote my own mock framework in Elixir called ExDoubles. I know, I know, there are tons of them already, but hear me out. This one seeks to act like mock libraries in other languages, and put focus on the key element of abstraction in Elixir, the function. Why? Why? Why? I have been working in Elixir for the last six months, after years of Ruby and C#.

So you have written an implementation for that new feature in your Rails app, but your team won’t accept your Pull Request until there are unit tests. What’s more your changes are to private methods of a class. In frustration, you shout, “How do I unit test this code?” The key to unit testing private methods, in any language, is to test them through the public ones. Through almost two decades of practicing test-driven development, and writing unit tests in many languages at several large companies, including GitHub and Pivotal Labs, I have found you have only two strategies for maintainable unit tests around pre-existing private methods.

I want to briefly speak to you about the strategies that I use when writing technical documentation on my teams. You may be wondering how you can write a document about the steps to deploy your application to your staging environment. In this case, I feel you should favor automation over writing documentation — as it is valuable to deploy an application or services in an automated fashion at a regular cadence.

“Welcome to Techtro,” says Tim, as he writes the daunting term on the whiteboard in black marker. The tall blonde man boldly stands in front of his bewildered team jammed in a conference room. He calmly returns their awestruck stare while placing the marker back on the ledge of the movable whiteboard. “Tech-what,” Mike asks with exasperation, turning to his coworker Liz, looking for a companion in his confusion. Her brown eyes echo Mike’s frustration, and he exhales in relief.

Two summers ago, I spent some time in Georgia. It was a different universe than the crowded streets and fast pace of New York City — where I live now. Laying down roots and connecting with people was as easy as breathing. Walking through the aisles of a grocery store, a stock clerk would ask, “How are you doing today?” When I looked back, he had stopped working and was waiting for my response.

Since most applications can be represented by state machines, it is beneficial to make valid states in your program as clear as possible and invalid states impossible. This will enhance the readability, and maintainability of your code to everyone who sees it, including future you. In the rest of this article we will discuss one strategy for making invalid states impossible with an example in tsx and React. Replacing Booleans With Types Below you will find a tiny React component that displays fish from a fictional API.