On Programming Well

Becoming a better software developer

Wed, 09 Sep 2015 00:00:00 +0000

If you’ve spent enough time programming software, chances are you’ve had quite a few “a-ha” moments where you realize your past efforts suck.

If you really like programming, you enjoy learning from those a-ha moments, and then spend a lot of time figuring out how to write better software.

After a while you’ll start to realize that software development is hard, and it’s tougher to become better if you’re in the “wrong” environment. It’s like trying to grow plants in barren land (not that I ever tried, but it sounds like it wouldn’t have the best results).

In Mexico, I spent my share of time trying to become a better software developer. But I realized it was not the best environment. Even though I tried (and I did become better), the biggest thing that hindered my growth was indifference.

1. The developers didn’t care

Some did, but most didn’t. Since developers didn’t care there was no one to look up to. In this types of environments, most of the time you’ll be learning the right lessons on your own. This was also true for the community. I’m sure things are changing (I’m talking about 3 to 5 years ago). I also believe there are companies out there with outstanding development practices, but it’s difficult to know about them all (especially if they don’t foster this culture outside, with the community).

2. The clients didn’t care

And because the clients didn’t care, there was not enough money to fund our self growth. Once I had enough knowledge to say with confidence that there was a better way, and that it was much more valuable, a lot of my effort went towards convincing new clients of this. Changing their mind was not difficult, but the bigger problem I faced was convincing my own co-workers that it mattered. This is essential if we are going to build better software, because one person cannot carry the others if they just don’t get it or don’t care bad enough. I’ve come to the conclusion that a team of professionals can grow exponentially as long as there are no “bad apples” slowing them down.

Once I had enough of this indifference, I decided not to fight against the current for a change, and come to the US to work first-hand with one of the companies that I admire, and was mentoring me indirectly anyway through books, blog posts, conference talks, etc: 8th Light. This company has a very high regard for well crafted software, and the people who work here care deeply about their craft. We try to improve every day, help each other, and our work environment fosters learning and self growth.

Some things we do that I wish I was doing back in Mexico:

Lead the industry by example
Identify knowledge gaps between newcomers and seasoned developers
Mentoring relationships between seasoned employees and newcomers
Share our knowledge outside of the company– conference talks, attending and hosting meet ups, writing blog posts, etc.
Identify developers who care, and support them to become better
Encourage developers to expand their knowledge by attending conferences, having a “self-edification” budget to purchase books, online courses, or anything that helps us improve

While not every US company is like this, in my opinion there’s a lot of lessons Mexico could learn from the general tech scene here. Leaders of the industry invite people over to their offices to talk about better software practices, or show the solution to hard engineering problems they faced. And they do it for free. Of course this is also a strategy to hire new talent, but anyone who wants to learn can attend these meet ups, and there’s usually a lot of qualified people willing to help. This is a whole different culture that not until recently Mexico started to adopt. I may be wrong because there are many cities in Mexico and I can’t speak for all of them. I’m from Monterrey which I think is a fair representation of other cities that are strong in tech, and I’m just talking about what I experienced there.

It surprises me that there are claims (like the article in this link) saying there’s a lack of qualified professionals in the tech industry in Mexico. In my experience the reality is that there are not enough qualified tech companies in Mexico. I think there’s a misunderstanding worth having a conversation over.

The tech leads of big Mexican companies need to improve their software practices, their own teams, and their hiring and training processes. With proper guidance it’s not difficult, but first of all they need to care and take their share of ownership instead of laying the blame on universities or novice developers for “not knowing” what the company needs (which is likely outdated and so specific to that company that it would be useless elsewhere). On top of that, the compensation these companies offer doesn’t even come close to what is offered in other countries for similar positions. I’m not saying that developers are perfect or that companies “should” pay more just because, my point is that software development does not have the same value in Mexico as in the US or other countries, and the reason, I believe is indifference. We can change that and show its real value by creating software of higher quality. But in order to achieve that we need developers and companies who care, and who are willing to make a joint effort instead of competing against each other for better compensation, or demanding long work hours, cranking out more features, faster, without actually backing them up economically.

The following statement will not apply to every company but it will apply to a great majority: until Mexican companies and developers recognize and experience the higher value of well crafted software, their products will not be top of the line, salaries will not be top of the line, and the general market offers will be mediocre (appealing to guess what kind of developers? the ones that don’t care, and companies complain about).

If you’re a software developer or tech lead of a company, and feel identified with some of what I described, please reach out to me. If you’re serious about becoming better I’ll do my best to help you out. I can at the very least recommend you some essential books that I really enjoyed and I know helped others. I’m also available twice a week for pair programming sessions.

Named Pipes

Sun, 08 Mar 2015 00:00:00 +0000

A couple of weeks ago I heard about named pipes, a very neat feature of unix-like systems. This feature allowed me to speed up my TDD cycle. In general, though, I think named pipes fall into the “good-to-know” category for your developer toolbelt.

First off all, a unix pipeline allows a set of processes to have their I/O chained together. A typical example that you’ve probably seen or used before is:

$ ls -l | grep Documents
drwx------+  3 jassa  staff   102 Feb  6 19:59 Documents

Each pipe ( ) connects the output of the left program, to the input of the right program. In this example we pass the output of ls -l (a list of files and directories) to grep Documents (which will return the lines that match our “Documents” search). Pipes have many useful applications, and named pipes are an extension of them.

A traditional pipe lives as long as the processes involved are running. A named pipe, on the other hand, is persistent and sits in your system like any other file. Whatever you write to it, can be read elsewhere. Here’s an example (we need two terminal sessions because reading/writing to a named pipe is I/O blocking).

# Terminal 1
$ mkfifo myNamedPipe # creates a file named “myNamedPipe”
$ echo "Foo" > myNamedPipe # send “Foo” to myNamedPipe
  # ..this process hangs until we read the contents of myNamedPipe elsewhere

# Terminal 2
$ cat myNamedPipe
Foo # returns immediately, and the process in terminal 1 also returns

Reading and writing to named pipes are I/O blocking operations. Both processes depend on each other and will be blocked until you read the contents of your named pipe. Our previous example with an anonymous pipe could become:

# Terminal 1
$ ls -l | grep $(cat myNamedPipe)
  # hangs…

# Terminal 2
$ echo “Documents” > myNamedPipe

# Back in terminal 1 our process returns…
drwx------+  3 jassa  staff   102 Feb  6 19:59 Documents

By now you should start to realize the power of named pipes. I switched to Vim recently (most people I work with use it, so in order to pair effectively I left Emacs for a while), and on top of that I started working on a Java project that uses maven to manage its build. I decided to avoid the typical slow and bloated IDEs, and just try a Vim workflow instead. I value simplicity, not just in my code but also in my tools, and named pipes allowed me to achieve a tight feedback loop without the overhead an IDE and third-party libraries bring into the mix.

Basically I created a custom autorunner for whenever my tests change, using Vim and maven.

My “manual” TDD workflow looks like this:

Make and save changes to SomeClassTest.java
Run mvn -Dtest=SomeClassTest clean test in a command prompt

In order to automate the 2nd step, I had to setup a couple of things in my terminal.

Create a named pipe (in my case mkfifo .test-class)
Run an endless loop that evaluates the name of the desired test class
```
  $ while true; do mvn -Dtest=$(cat .test-class) clean test; done
```
This endless loop will be blocked waiting to read from the .test-class pipe. If we echo “SomeClassTest” > .test-class it will run the given test and block again waiting to read.

The last step is making Vim write the class name to the pipe every time we save our changes. In my project’s local .vimrc (See the exrc option):

:autocmd BufWritePost *Test.java :call RunTest()

function! RunTest()
    :call system('echo ' . expand('%:tr') . ' > .test-pipe')
endfunction

This function runs every time we save a file that ends with Test.java, and passes the current file name to our named pipe. Now my tests run automatically whenever I save my changes. It might not look like much, but consider the seconds saved from every time I had to switch to another tab, hit the up arrow and press enter (or alternatively reverse-i-search for “test”).

What I liked the most about this approach is that with a couple tweaks you can reuse it for pretty much any language and environment.

This is only the first use that I give to named pipes. Like I said, it’s probably one of those features that are useful to know about, but probably not immediately. I don’t think I have any other use for them right now, but I bet if I encounter a problem they can solve, they’ll pop up in my head.

Loose coupling in Go lang

Thu, 22 Jan 2015 00:00:00 +0000

Go lang offers a wide range of features that help us achieve loosely coupled program designs. In this blog post I will talk about interfaces and higher-order functions.

1. Interfaces

In Go we can define a type interface by supplying a set of method definitions:

type /* name of interface */ interface {
     // method definitions, that is without implementation
     // e.g. sum(a, b int) int
}

Let’s say we’re working on a chess program, and we want to define an interface to present the game in multiple I/O devices. We need a method to get the input from the user, and another one to present the output.

type IO interface {
	Read() string
	Write(message string)
}

When we call Read we expect a string back, and when we call Write we pass in a message. In Go, any value that implements those two functions satisfies the interface. For example:

type CommandLine struct{}

func (cli CommandLine) Read() string {
	var input string

	fmt.Scanf("%s\n", &input)

	return input
}

func (cli CommandLine) Write(output string) {
	fmt.Printf("%v", output)
}

This is especially useful for testing. We can create a FakeIO type and have complete control over its input and output to verify their contents.

type FakeIO struct{
	Input string
	Output string
}

func (io FakeIO) Read() string {
	return io.Input
}

func (io FakeIO) Write(output string) {
	io.Output = output
}

Now we can stub and spy calls to I/O in our tests. Suppose we want the player to enter his name when we start a new game:

func (player Player) GetName(io IO) {
     io.Write("What's your name?")
     player.Name = io.Read()
}

func TestGetPlayerName(t *testing.T) {
	var io FakeIO

	io.Input = "Javier"
	player.GetName(io)

	if name := player.Name; name != "Javier" {
		t.Errorf("Expected name to be %#v, but was %#v",
			"Javier", name)
	}
}

And it’s just as easy to verify the game output, we’d just check the value of io.Output when testing functions that use io.Write(string).

2. Higher-order functions

In mathematics and computer science, a higher-order function (also functional form, functional or functor) is a function that does at least one of the following:

takes one or more functions as an input

outputs a function

Go is strongly typed, which can complicate the use of functions as a means of injecting dependencies. Continuing with our chess game, consider the problem of playing against the computer.

When it’s the human player’s turn, we have to pass the chess board and the IO interface to get the move input, which could be a mouse click in a GUI, or text entered through the command line, etc.:

player.Move(io, chessBoard)

The computer on the other hand, has no need for an IO interface to supply its move. It calculates what to do based on the current state of the chess board.

computer.Move(chessBoard)

An implementation of the game loop could look like this:

for !chessBoard.HasCheckMate() {
	player.Move(io, chessBoard)
	computer.Move(chessBoard)
}

As you may notice, the problem with the loop above is that we’re not checking for the end game condition before the computer moves, so if the human wins, the computer will still attempt to move. This can be easily solved if we create an endless loop instead, and guard each player move with HasCheckMate()

for {
	if !chessBoard.HasCheckMate() {
		player.Move(io, chessBoard)
	}

	if !chessBoard.HasCheckMate() {
		computer.Move(chessBoard)
	}
}

But I’d rather avoid duplication (consider what happens if we want to add a third player, and a fourth, and so on).

It’d be nice to store the players in a data structure, and cycle through it to get the player for each turn. Then we’d be able to write something like this:

for !chessBoard.HasCheckMate() {
	getCurrentPlayer().Move(...)
}

Storing the references to the players wouldn’t be enough, though, because of the different arity in their Move functions. If we really wanted the function above to work there are a few approaches we could try, but I won’t be doing that in this blog post. Instead, I’m going to use Go’s anonymous functions to store the Move functions, not the players.

var playerMove = func(chessBoard chess.Board) {
	player.Move(io, chessBoard)
}

var computerMove = func(chessBoard chess.Board {
	computer.Move(chessBoard)
}

var moves = []func(chessBoard chess.Board) {
	playerMove,
	computerMove.
}

The anonymous functions receive only the chess board, so arity is no longer an issue and we can store them in an array. Finally our game loop can look like this:

for !chessBoard.HasCheckMate() {
	moveCurrentPlayer(chessBoard)
	changeTurn()
}

And calling move on the current player is trivial:

func moveCurrentPlayer(chessBoard chess.Board) {
	moves[0](chessBoard)
}

To change the player turn, simply cycle through the contents of the moves array.

These are only some of the language features that we can use to achieve loosely coupled designs. In this example we used interfaces and higher-order functions to comply with the language constraints while keeping our code concise and easy to test.

On an ending note, I find Go features very refreshing. Out of the box it’s simple and powerful. It provides just enough utility functions (through its src packages), so you don’t have to reinvent the wheel. Go treats functions as first-class citizens, and that’s my favorite feature of the language so far.

The Craftsman Toolbelt

Thu, 18 Dec 2014 00:00:00 +0000

This past couple of weeks I had the opportunity to pair with eight different craftsmen and craftswomen. We worked on very different codebases, from small startups to giant companies, on Scala, Ruby, JS, Clojure, Java… I learned a lot from each one of them.

I’ll try to sum it up in what I’ll call “the Craftsman Toolbelt”. Even though we were working on different environments, with different levels of information (some times we had the big picture, sometimes we had nothing), I saw many skills and disciplines at play when tackling the problem at hand.

TDD

The most evident discipline for me was TDD because there’s a lot of hype around it. When we were dealing with an unknown language, or library, or system, or all three combined, we could rely on TDD to ensure we’re doing what we mean to. This was an eye opener about the importance and utility of test-driven development.

Communication

Communicating through code

Personally this is my favorite type of communication because it’s never out of date. Written documentation outside of the codebase can lie, people can lie, even comments can lie. The best way to know for sure what’s going on is to look at the code, and if it’s written with an audience in mind then you won’t have any troubles understanding it. Craftsmen know this and write their code considering future developers.
Written documentation outside of the codebase

In reality, some programmers just won’t care for the next person reading their code and they’ll tackle the problem as quickly as possible, leaving a mess behind. This is were documentation comes in handy, instead of jumping around between incongruent functions across files and servers, you can expect that the documentation is somewhat up to date and use it as a resource to get a better general picture of what you can work with.
Communication with the client

Sometimes the documentation and the code are working and they’re easy to understand, but they are solving the wrong problem. It’s important to talk with the client to make sure you’re on the same page. There are cheap ways to ensure you keep on the right track, such as weekly meetings, creating user stories, and defining acceptance criteria before you write any code.
Communicating about the project status and road map

Sometimes after working on a problem for a while, we would find our estimates were off and there was no way we could finish as soon as we expected. The craftsmen I paired with did a fantastic job communicating with the client and the rest of the team, and managed their expectations accordingly. Solving a given problem will take time, how long depends on the elegance of the solution, a skilled craftsman will consider multiple options, their trade-offs, and do what works best for each client. Even when there are setbacks, honest communication can go a long way. This is why trust is essential in software business relationships, and we gain trust by consistently delivering what we say we will.

Curiosity

I don’t think this is a discipline but a quality instead, when we didn’t know much about the tools or the system, craftsmen were curious and explored what they had control over, to see what resources they had at their disposal and solve the problem.

It was a really great experience to pair with everyone and see how they think, what they value, and how they interpret and apply the principles of software craftmanship.

Formatting Patterns Picks: Cascade

Tue, 02 Dec 2014 00:00:00 +0000

Formatting (done right) makes code easy to read and understand. In a team, formatting code the same way is important because it helps each member feel comfortable working on a shared codebase.

Kent Beck defines ten Formatting Patterns for Smalltalk. I found the Cascade Pattern particularly interesting. Essentially it’s a clean and simple way to pass multiple messages to one receiver. I haven’t seen anything so simple in another language before (which is odd since in OOP we pass messages all the time).

A Cascade sends multiple messages to one receiver. Think of it as chaining, but each message goes to the first receiver.

In the following example, we send three messages to a rectangle instance:

rectangle color: Color red.
rectangle height: 10.
rectangle width: 20

In Smalltalk, we can write the code above as:

rectangle
    color: Color red;
    height: 10;
    width: 20

Simple, right?

Cascades can be misleading when used directly on a class, though:

Collection new
    add: 1;
    add: 2;
    add: 3

Remember each message is going to the first receiver, so the code in the example above will return a collection with only one entry (the number “3”).

Use a Cascade to send several messages to the same receiver. Separate each message with a semicolon. Put each message on its own line and indent one tab. Only use Cascades for messages with zero or one argument. (Kent Beck)

Kent recommends that we use Cascades only to send messages with one or zero arguments, otherwise the readability gains are lost because the reader has to figure out which messages are being sent. E.g. in the code below we end up with two entries instead of one.

Collection new
    add: 1;
    add: 2
    add: 3

All in all I think this is a nice feature of Smalltalk that would be very useful in modern languages.

Reference

Smalltalk Best Practice Patterns

Behavior Patterns Picks: Reversing Method

Mon, 01 Dec 2014 00:00:00 +0000

The Reversing Method pattern (as defined in Smalltalk Best Practice Patterns) is useful to code a smooth flow of messages.

Problem: a Composed Method may not read right because messages are going to too many receivers. You may have a Cascade that doesn’t look quite right because several different objects need to receive messages.

A Composed Method divides functionality into smaller methods. A Composed Method might become hard to read if we’re sending messages to many receivers.

Consider the following example:

Point>>printOn: aStream
    x printOn: aStream.
    aStream nextPutAll: ' @ '.
    y printOn: aStream

We’re sending messages to three different objects; x receives printOn, aStream receives nextPutAll, y receives printOn. You don’t have to know much Smalltalk to understand from the code above that our intent is to define a printOn method that will print a formatted Point instance into a stream.

The Reversing Method makes sure that all the messages go through a single object, which improves readability (as we’ll see next) and by having the object receive all the messages it can vary without affecting the parameters.

Code a method on the parameter. Derive it’s name from the original message. Take the original receiver as the parameter to the new method.

"code a method on the parameter (a 'stream'), derive the name from the original message ('printOn')"
Stream>>print ...

"take the original receiver ('x' and 'y') as the parameter of the new method"
Stream>>print: x
Stream>>print: y

"or more succinctly"
Stream>>print: anObject

Implement the method by sending the original message to the original receiver.

"send the original message ('printOn: aStream') to the original receiver ('x' and 'y', or 'anObject')"
Stream>>print: anObject
    anObject printOn: self

Finally:

Point>>printOn: aStream
    aStream print: x.
    aStream nextPutAll: ' @ '.
    aStream print: y

This is much easier to follow than the example we started with. Smalltalk takes readability one step further with the use of Cascades (which I’ll cover on my next post, but here’s an example)

Point>>printOn: aStream
    aStream
        print: x;
        nextPutAll: ' @ ';
        print: y

Great code has a rhythm that makes it easy to understand. Code that breaks the rhythm is harder to read and understand. (Kent Beck)

Refactoring the three laws of TDD

Wed, 26 Nov 2014 00:00:00 +0000

Uncle Bob describes TDD with three rules:

You are not allowed to write any production code unless it is to make a failing unit test pass.
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Read them carefully and you’ll notice they’re simpler than they look like, but they have a lot of repetition so here’s a “refactored” version:

Write production code only to make a failing unit test pass.
Write only enough of a unit test to fail.
Write only enough production code to make the failing unit test pass.

It’s obvious now that rule 3 implies rule 1, so here’s a concise version that I’ve found easier to remember:

Write only enough of a unit test to fail.
Write only enough production code to make the failing unit test pass.

This couple of rules also serve me as a checklist when I’m developing, so I just repeat them in order, over and over, to keep me in the TDD loop.

Reference

The Three Laws of TDD

Behavior Patterns

Mon, 24 Nov 2014 00:00:00 +0000

In objects, we model the world around us via behavior and state. The operations performed by the object define it’s behavior, and the objects specify their behavior via methods and messages.

Objects can hide their representation behind messages:

class House

  def build
    install_floor
    raise_walls
    add_roof
  end

end

Code is easier to read when we decompose functionality and use messages. In the example above, we can see that in order to build a house we install the floor, raise the walls, and add a roof. These methods handle the details of the implementation, and might even be broken down into more messages depending on the complexity of the task.

Decomposing the functionality of your program into smaller, digestible, and carefully named methods clearly communicates your intentions to the reader.

Centralizing the meat of the algorithm might make code easier to follow, since you don’t have to jump around from file to file to understand it, but this approach leads to rigid systems. If you break up behavior into many methods and pass messages around to carry out tasks, you increase flexibility by essentially making your objects replaceable. Managing many bits and pieces of code takes time and effort, sometimes bigger methods could be better if the management overhead outweighs the benefits of decentralizing the flow of control.

In Smalltalk Best Practice Patterns, we can find an extensive list of behavior patterns gathered by Kent Beck. He splits behavior patterns into methods and messages. Method patterns deal with the decomposition of a program into methods, and how to write those methods throughout your system, while Messages patterns deal with how to compose and decompose your messages, and how to pass those messages between the components of your system in order to achieve complex tasks.

It’s really interesting to put a name on strategies I’ve used in the past and see why they work. I found a few pretty cool patterns that I didn’t know about, but they’re exclusive to Smalltalk. I’ll write about my favorites on a separate blog post.

Introduction to Smalltalk Best Practice Patterns

Wed, 19 Nov 2014 00:00:00 +0000

A pattern is a decision recommended by experts to solve recurring problems in software engineering. For example, delegating work to one of many possible objects is a pattern, and even though the actual objects and messages being passed around will differ on each implementation, they have several constant qualities.

Smalltalk Best Practice Patterns, by Kent Beck, is written under the premise that problems in software development are universal: we all have to name variables, functions and classes, relate entities, cope with change, and so on. Patterns offer an approach refined through experience to solve these problems.

Some of the key benefits of understanding and using them:

Read and understand code more quickly

When you identify a pattern in the code you’re working on, it’s easier to understand why it’s written like it is. If you know what to expect you can understand the system faster.
Make everyday development decisions with confidence

Kent Beck suggests attempting to back up every line of code you write with a pattern. He mentions that at first it will slow you down, but as you practice and internalize them, you’ll gain your old speed with the added benefit of writing much cleaner code.
Common language and values for code reviews

If your team is familiar with patterns, you can use them as reference in code reviews and suggest legitimate improvements for existing code.
Describe a system with fewer words

Patterns carry meaning. If you communicate with patterns and your audience understands them, you can say more with fewer words. For example, think of how many more words you’d need to describe “a broken computer” without using the word “computer”. Each pattern embodies a concept.
Clean up complex systems

When you’re working on a system for the first time, you can use patterns to clean the code to make it readable and more understandable. Kent beck mentions he used this approach to clean code and at the same time understand the system. Once he went through the system and understood what needed to change, the code was already clean to make changes without much effort.

Build and validate your own web server

Mon, 10 Nov 2014 00:00:00 +0000

I’m creating a web server to practice my programming skills/improve my knowledge, I’d say it’s from scratch but I’m using Java sockets which handle a big deal of complexity.

My challenge then is creating an implementation of the HTTP protocol to handle the communication between server and clients.

Our web server must be prepared to interpret HTTP requests and build a proper response.

A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.

The first line of the request message must include:

Method (GET, POST, HEAD, etc.)
Request-URI (to be affected by the method)
HTTP-Version (protocol version, in this case HTTP/1.1)
CRLF (US-ASCII CR, carriage return (13), US-ASCII LF, linefeed (10), in other words a line terminator or newline)

The elements should be separated by SP characters (US-ASCII SP, space (32)).

After receiving and interpreting a request message, a server responds with an HTTP response message.

The response should begin with:

HTTP-Version (same as above, HTTP/1.1)
Status-Code (3-digit number that represents the result of processing the request, see full definitions)
Reason-Phrase (short textual description of the status code)
CRLF (line terminator)

And again, the elements must be separated by the defined SP characters.

These are the basic elements of HTTP requests and responses, the web server implementation gets more complicated as you support different media types, streaming, concurrent connections, etc.

In order to validate that our web server adheres to the HTTP protocol, we can use a suite of acceptance tests called Cob Spec. The tests were written using a framework called FitNesse which runs in your browser as a wiki. It’s very easy to use and the installation is fairly straightforward, just go through the instructions in the project Read Me. At the time of writing I just had to clone a couple of GitHub repos, and have Java and Ruby installed.

Once you run Cob Spec you can access the tests suite in your browser, which lists the different test cases. You’ll have to edit a couple of variables (from the website) in order to run them.

To run a test case go to “HttpTestSuite” from the main menu and navigate through the list, then click “Test”. Otherwise click “Suite” to run everything.

Cob Spec will start your server on each test case (given a command you specify in your variables, e.g. /path/to/server/bin/run), then it will send different requests to your server and expect the appropriate response.

Here’s a screenshot of a test passing for a simple GET request:

In this example, the test passes when it receives an HTTP response with a status code of 200 (OK).