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:

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:

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.

When test-driving a system, it can be tricky to know which type of test to use and when. Rather than talk about the testing pyramid, I want to focus on the questions we want answers to. Below I have organized feature tests, integration tests and unit tests by the questions that they answer. Is It Wired Together? Whenever I start working on a new feature for a system, I begin by writing a failing feature test.

Maintain shared behavior of multiple implementations by making them pass the same tests. Motivation When building a system, there may emerge a subsystem or class that has to share a baseline set of behavior with other implementations, while providing other non-functional requirements. The shared behavior can be shown to exist by using a contract test. Example Test doubles are a great way to reduce overall speed of the test suite by only running tests against in-memory versions of external services.

I find that there are two moments that best suit using refactoring; practicing TDD and adding new features. As part of the TDD flow, we restructure the code we wrote in the last ten minutes, after the red and green stages. We iterate until we find a design that is the best we can think of at the moment, for the features we have now. The best designs follow the Four Simple Rules Of Design.

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.

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.

Our process has failed us! The payment feature went offline, our team doesn’t have shippable code, and a user story has been in progress for two weeks. In order to deliver software at a consistent pace, it is essential that agile teams iterate on how they work. Below I describe the steps to facilitate a retrospective to address these problems. So that this post is useful as a reference, I have made each facilitation step a header followed by a recommended time box.

While I was researching different ways for teams to increase their throughput, I stumbled upon a distinction that is often not made. Framework is often used to refer to both the framework pattern and subsystem pattern. Here is a short description of those two patterns and their tradeoffs. Frameworks Frameworks are skeletal structures of programs that must be fleshed out to build a complete application — Rebecca Wirfs-Brock Examples Spring and Rails are examples of frameworks.

Product and engineering need to see each other as co-signers on technical debt. The idea isn’t to say “no” to all technical debt, as you will definitely have to take some on. Rather, we need to have open and honest discussions about the state of the code and why certain design elements need to be fixed now and which ones can be deferred. Collectively balancing the need to deliver in the short vs long term.

Writing software is at its core a production system. The goal is to produce a product with just the right quality, at just the right time, so that customers find it valuable. With that in mind, let’s look at the types of things that can stop us from producing on time or at the right quality. There are 7 types of waste in a production system. They are: Defects — product is low quality Over processing — product has excess quality Waiting — people are blocked Transportation — moving product in a way that doesn’t add value Inventory — product is stuck between phases Motion — moving people that doesn’t add value to the product Excess production — producing quantity than is valuable to customers Blocked Stories Are Inventory I want to focus in on one of these types of waste, inventory.

Years ago, I watched Kent Beck’s talk on finding ease at work. He described death marches and unsustainable pace. He told stories of people having their humanity ignored, resulting in burn out and depression. Though, I was yet to experience life as part of a development team, my college experience allowed me to identify with those stories. He went on to discuss the pendulum swing between two states of engineering, the highs of being the team hero and the lows of being a failure.

Is your development team frustrated? Do they seem like they are going slower? Maybe you ask yourself, “Are they working hard enough?” They need something called slack — no not that chat app. They need time to reflect on their processes and try new ones to see if they can work more effectively. “How is that possible,” you ask. The answer is a techtro. Techtro: is short for technical retrospective. It is a chance for your software team to focus in on the technical process, reflect, and take action.

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.

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.

Maintain shared behavior of multiple implementations by making them pass the same tests. Motivation When building a system, there may emerge a subsystem or class that has to share a baseline set of behavior with other implementations, while providing other non-functional requirements. The shared behavior can be shown to exist by using a contract test. Example Test doubles are a great way to reduce overall speed of the test suite by only running tests against in-memory versions of external services.

I built a small framework, which retaught me why it is important to understand a user’s problem, ship early and iterate. Yes, even for frameworks. It kicked off with a tweet, which expressed disdain for Ruby’s nil. The author yearned for a maybe implementation. Having just finished the Bowling Kata in Elm, a language which has a built-in Maybe type, I decided I could create a quick implementation. I didn’t anticipate how long quick was…

I want to tell you about an alternate design technique, it is called programming by intention. Rather than writing code that describes how to perform some action, you call a function. The interesting thing is the function doesn’t exist. Yet, we are going to call it as if someone wrote it ten minutes ago. We are going to follow a loop of call a function that doesn’t yet exist, implement what it does by calling more functions that don’t exist, until we have to implement the real code.

DRY is commonly interpreted to mean that code should not have duplicate structures. For instance two array indexes that both use rand(4) would be refactored away. Let’s look at an example of code that does exactly that. Person.new(names[rand(4)], jobs[rand(4)]) At some point, this is perceived as duplication and an abstraction is put in place. This abstraction is not logically consistent with the domain logic. Person.new(random_item(names), random_item(jobs)) At first this inconsistency is not inherently dangerous.

In the words of Jimmy Two Times, “I’m gonna go get the papers, get the papers.” The Don’t Repeat Yourself (DRY) Principle is commonly interpreted to mean, code with no duplicate statements. I’d like to explore that thinking with you for a few minutes so that I can demonstrate how it is flawed. I have written a small program that displays the name and job of randomly created people. Take a look at the :random_person function.

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.

Maintain shared behavior of multiple implementations by making them pass the same tests. Motivation When building a system, there may emerge a subsystem or class that has to share a baseline set of behavior with other implementations, while providing other non-functional requirements. The shared behavior can be shown to exist by using a contract test. Example Test doubles are a great way to reduce overall speed of the test suite by only running tests against in-memory versions of external services.

I built a small framework, which retaught me why it is important to understand a user’s problem, ship early and iterate. Yes, even for frameworks. It kicked off with a tweet, which expressed disdain for Ruby’s nil. The author yearned for a maybe implementation. Having just finished the Bowling Kata in Elm, a language which has a built-in Maybe type, I decided I could create a quick implementation. I didn’t anticipate how long quick was…

I want to tell you about an alternate design technique, it is called programming by intention. Rather than writing code that describes how to perform some action, you call a function. The interesting thing is the function doesn’t exist. Yet, we are going to call it as if someone wrote it ten minutes ago. We are going to follow a loop of call a function that doesn’t yet exist, implement what it does by calling more functions that don’t exist, until we have to implement the real code.

DRY is commonly interpreted to mean that code should not have duplicate structures. For instance two array indexes that both use rand(4) would be refactored away. Let’s look at an example of code that does exactly that. Person.new(names[rand(4)], jobs[rand(4)]) At some point, this is perceived as duplication and an abstraction is put in place. This abstraction is not logically consistent with the domain logic. Person.new(random_item(names), random_item(jobs)) At first this inconsistency is not inherently dangerous.

In the words of Jimmy Two Times, “I’m gonna go get the papers, get the papers.” The Don’t Repeat Yourself (DRY) Principle is commonly interpreted to mean, code with no duplicate statements. I’d like to explore that thinking with you for a few minutes so that I can demonstrate how it is flawed. I have written a small program that displays the name and job of randomly created people. Take a look at the :random_person function.

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.

Years ago, I watched Kent Beck’s talk on finding ease at work. He described death marches and unsustainable pace. He told stories of people having their humanity ignored, resulting in burn out and depression. Though, I was yet to experience life as part of a development team, my college experience allowed me to identify with those stories. He went on to discuss the pendulum swing between two states of engineering, the highs of being the team hero and the lows of being a failure.

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.

Are you currently the only one on your engineering team who can read and understand your code? If you left for a new job, how often would your teammates need to call you in order to maintain the code you left them? Let’s talk about how to not get calls after you leave a job. Visual Hierarchies Visual hierarchies are a powerful tool. As readers they allow us to scan, giving us a sense of the main flow.

I want to tell you about an alternate design technique, it is called programming by intention. Rather than writing code that describes how to perform some action, you call a function. The interesting thing is the function doesn’t exist. Yet, we are going to call it as if someone wrote it ten minutes ago. We are going to follow a loop of call a function that doesn’t yet exist, implement what it does by calling more functions that don’t exist, until we have to implement the real code.

DRY is commonly interpreted to mean that code should not have duplicate structures. For instance two array indexes that both use rand(4) would be refactored away. Let’s look at an example of code that does exactly that. Person.new(names[rand(4)], jobs[rand(4)]) At some point, this is perceived as duplication and an abstraction is put in place. This abstraction is not logically consistent with the domain logic. Person.new(random_item(names), random_item(jobs)) At first this inconsistency is not inherently dangerous.

In the words of Jimmy Two Times, “I’m gonna go get the papers, get the papers.” The Don’t Repeat Yourself (DRY) Principle is commonly interpreted to mean, code with no duplicate statements. I’d like to explore that thinking with you for a few minutes so that I can demonstrate how it is flawed. I have written a small program that displays the name and job of randomly created people. Take a look at the :random_person function.

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.

Are you currently the only one on your engineering team who can read and understand your code? If you left for a new job, how often would your teammates need to call you in order to maintain the code you left them? Let’s talk about how to not get calls after you leave a job. Visual Hierarchies Visual hierarchies are a powerful tool. As readers they allow us to scan, giving us a sense of the main flow.