Testing Applications

Testing is critical to creating robust applications, and yet testing is very often avoided, or overlooked by developers. I believe part of the reasoning is that companies prioritize application feature speed to market over quality and robust application development. Another reason is that proper automated testing is considered difficult, whereas manual testing of an application is seen as the easier solution.

Within this chapter, we will tackle the problems and solutions of testing applications within Go and more specifically, how we can test our Echo web applications. We start by covering the five primary categories of application testing and then progress into how each type of testing can be accomplished for our example web application. It will be shown how handler and middleware functions can be tested independently of the entire system. You will learn...

Technical requirements

You will be required to know Go programming language, also basics of web application framework. You will also need to install Git, in order use the Git repository of this book. And finally, ability to develop with an IDE on the command line.

The code files of this chapter can be found on GitHub:
https://github.com/PacktPublishing/Echo-Essentials/tree/master/chapter7

Check out the following video to see the code in action:
https://goo.gl/PtZgpP

Types of testing

Testing in general can be broken into five primary categories:

• Unit testing
• Benchmark testing
• Behavior testing
• Integration testing
• Security testing

Unit testing

Unit testing is a form of testing that is close to the application code itself. Often times, unit test code lives directly adjacent to the feature code within the code base. The goal of unit testing is to provide a quick answer to the question: Does this unit of code do what I think it should be doing? This is the first level of testing that is typically performed, as it lives and runs against the lowest unit of functionality.

Benchmark testing

...

Unit testing middleware and handler code

Luckily for developers, unit testing in Go is completely contained within the standard library. In other languages, it is often the case you need to use a third-party library for the creation and running of unit tests. Within Go, the standard library contains all of the tools needed to write, run and analyze unit tests. Within this section, we will learn how to write tests in Go, but also how to use Echo within our tests.

We will start with the small example test given here, which primarily unit tests our simple /health-check endpoint. To start out, all tests within Go have a very special naming convention. The filename must end with _test.go and must be within the same package, or directory, of the code it is trying to test. Often times in other languages and frameworks, you have the flexibility to create a dedicated test/ directory in...

Benchmark testing web applications

Much like unit testing, benchmark testing within Go is very simple, as Go provides a great abstraction. Also like unit testing, there is a strong convention for naming your benchmark tests. Benchmark tests need to include the word Benchmark at the beginning of the function name. In addition, the parameter expected is the *testing.B type instead of the *testing.T structure. Here is an example in which we benchmark our /health-check endpoint, which can be found in $GOPATH/src/github.com/PacktPublishing/Echo-Essentials/chapter7/handlers/health_check_test.go:

func BenchmarkHealthCheck(b *testing.B) {
        e := echo.New()
        e.Pre(middlewares.RequestIDMiddleware)
        e.GET("/health-check", HealthCheck)

        w := httptest.NewRecorder()
        r, _ := http.NewRequest("GET", "/health-check", nil)

     ...

External behavior and integration testing

As seen, the creation of unit tests and benchmark tests within Go is very simple and intuitive. The built in go test command allows various coverage capabilities. A little known capability of the go test tool is the ability to specify which packages you wish to generate coverage information about with the -coverpkg flag. Armed with this information, we can formulate a go test command that will be able to run against the main package in our program but collect coverage information about our handlers package:

go test -coverprofile=cov.txt -coverpkg ./handlers -run TestRunMain ./cmd/service/

The preceding command is saying run tests against the main package but collect the coverage information from handlers that in turn will use the cover tool to instrument the handlers code to keep track of coverage numbers in the handlers package. If we...

Summary

As you can see, testing can be quite involved, and overwhelming to a developer, but it is currently, with the exception of formal method modeling, the only way to be sure your code is doing what you say it is doing. Empirical analysis on instrumented code can show you each and every line in your code that is “covered” by a test. This coverage information is good and bad. It is good because you have a number which marches forward or backward that you can use as a gauge of how much quality your code has within. It is bad because, just like any other gauge, developers can tweak the coverage numbers without actually increasing quality. By merely running code within the testing framework, the coverage number will increase but if your tests do not have valid assertions and are looking for the right things, the test is bunk. A pragmatic and honest approach to testing...