In today's episode, we delve into the testing tango and the art of Arrange, Act, and Assert (AAA), a practice that is essential when writing tests in order to structure them in a way that is coherent to other developers who may come across them. We discuss how to go about Arranging variables, how to use those variables (or Act), and then Asserting those specific behaviors. You’ll learn about the importance of having only one assertion per test and the benefits of leaving blank spaces or new lines for future reference. You’ll also discover an alternative approach to AAA called "Given, When, Then.” Tune in for these insights and some helpful tips that other developers and future you will thank you for!
[INTRO]
[00:00:01] MN: Hello and welcome to The Rabbit Hole, the definitive developers' podcast. Living large in New York, I’m your host, Michael Nunez. Today, we'll be talking about The Testing Tango and astering the Art of Arrange, Act, and Assert.
I was thinking about this topic as I've been bouncing around from client to client, and see how test is arranged in certain places, and wanted to kind of bring this up for discussion. In thinking about this particular topic, it might be a little testing series. There is another tango that we normally do, and the tango being red-green refactor when we're actually writing tests. So that might come up later in the future.
Before I continue on, I just want to say thanks to all the listeners right now who are currently listening. I completely missed the ball of our 300th released episode, which is kind of insane. It's been a journey as we started out around 2017 and continued on through the pandemic. It's post-pandemic now. I'm still working from home with the mic, talking to you all. So thank you for listening, participating, and reaching out for feedback. It's greatly appreciated.
Talking about the Arrange, Act, and Assert, this is normally a practice you would do when you are writing your tests. I hope that those who are listening are writing their code test first in test-driven development fashion. You may have heard of Arrange, Act, and Assert or AAA, like the car company that helps you out, roadside assistance. But the idea is to structure your tests in a way that makes sense when another developer comes in and looks at the test.
Say you had a particular test. First thing you want to do is you want to arrange all the variables. You want to write what is the expected. You want to write, if you had to go and fetch for a particular shape, get the shape name instantiated or a particular number instantiated. All that stuff is arranged so that it makes sense. You ensure that you write your variable names correctly and clearly so that someone can come in and understand what's happening.
Please don't use pqx or whatnot for that. Understand that there are certain languages that kind of lean into that. I'm looking at you Golang. But I'm a person who is very verbose about the variable names that I use. It's probably my Java habits. So as long as it makes sense in your programming language of choice that you're currently writing in, you want to arrange those variables in a way that makes sense for the next developer or you in six months to look at it.
The next part of the A is the Act. So this is the part where you would use the variables that were created in the Arrange portion. You may have to inject those variables into your method in order to then act on it, right? Oftentimes, you'll return an object. That could be your – the name could just be Act. Ensure that you are acting correctly and that you're calling the right function, that it's going through the right method, if you will.
Lastly, there is Assert. So the idea being that you take what you expected, right, if you put that in your Arrange, and you Assert that particular behavior. So if you got an actual object, you will Assert that your expected equals your actual. If you expected a particular behavior to happen, then this is where you would go and check like, “Hey, was this button clicked,” for example. How many times was it clicked and that kind of thing.
One thing to note of that I've seen, people often will add multiple assertions. I am of the party that it should only be one assertion per test. I think it makes it a lot easier, as mentioned in many other pieces of literature. It makes it very easy to understand where the test failed and why when you have one Assert per test, right? So like if you are testing a button, and that it was clicked twice, and that the text should say something else, and the color should have changed and done a different thing, if that one test fails, you don't know whether it is the text or the text color or the amount of clicks that happen. So you always want to separate those tests out and assert one thing at a time.
Now, interestingly enough, I actually saw in a code base a different way of the AAA, Arrange, Act, and Assert. The person used the idea of Given When Then, right? The idea is like, oh, “given” you have these variables and the particular way to set up this particular function, when you call that function with the “givens” that were created before, then you do your assertions that way. I thought that was an interesting take on the AAA because it kind of translates something that a developer may get from a user story.
We often Given When Then for acceptance criteria and stuff like that, I still think in the eyes of the Arrange, Act, and Assert, although I'd be interested to hear if there are folks out there who have either seen Given When Then or use Given When Then because it's just like a different way of doing the same thing. It's to organize your code so that future you will see that and say, “Oh, yes. No, I get it. The title of this test matches the way that I arranged it and what I'm asserting, given that I acted on something,” the idea of organizing your code.
Oftentimes, I would, for the Arrange, Act, and Assert, I will leave a blank space or like a new line separating the two to kind of let future me know that these are the sections of Arrange, Act, and Assert. I've seen people who also leave comments where they put Arrange, Act, and Assert, I think. I'm not a really big fan of adding comments to code. But if that's an agreement that you have with your team, then by all means, keep it going. Don't fight your team if this is a standard that's already implemented.
But Arrange, Act, and Assert does help you, future you, and other developers when looking at tests to ensure that the title of the test is clear, the names of the variables that you've arranged are clear, you've acted on the right thing, and that you're doing one assertion per test.
[OUTRO]
[00:07:18] MN: Follow us now on Twitter @radiofreerabbit, so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers just like you find their way into The Rabbit Hole. Never miss an episode. Subscribe now, however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries, and my amazing co-host, Dave Anderson, and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
