Revel provides a testing framework that makes it easy to write and run functional tests against an application.
Tests needs to be in the
myapp/ app/ conf/ public/ tests/ <----
A simple test file looks like the following:
The example code above shows a few things:
- A test suite is any struct that embeds
After()are invoked before and after every test method, if present.
TestSuiteprovides helpers for issuing requests to your application and for asserting things about the response.
- An assertion failure generates a panic, which is caught by the test harness.
- Each test method must contain the case-sensitive prefix ‘Test’
You may run this test in two ways:
- Interactively - from your web browser, useful during test development.
- Non-interactively - from the command line, useful for integrating with a continuous build.
Developing a test suite
To create your own test suite, define a struct that embeds
provides a HTTP client and a number of helper methods for making requests to the application.
All request methods behave similarly:
- They accept a path (e.g.
- They issue the
Requestto the app server
- They store the response in the
- They read the full response body into the
If the developer wishes to use a customized HTTP Client instead of the default http.DefaultClient, they should replace it in the
All assertions raise a panic if they are not fulfilled. All panics are caught by the test harness and presented as errors.
Running a test suite
module.testrunner = github.com/revel/modules/testrunner
You must also import the test module’s routes, by adding this line to your
Running tests interactively
To take advantage of Revel’s hot-compile functionality, an interactive test runner is provided for quick edit-refresh cycles.
For example, the developer loads
/@tests in their browser:
Then they add a test method:
Then they refresh their browser to see their new test:
They run the test:
Uh oh. It doesn’t work. They fix the code to expect a content type of “text/html” instead of “text/xml”:
Then they re-run the test:
Running tests non-interactively
The Revel command line tool provides a
test command that allows all application tests to be run from the command line.
Here is an example session:
$ revel test github.com/revel/examples/booking dev ~ ~ revel! http://revel.github.io ~ INFO 2012/11/09 19:21:02 revel.go:237: Loaded module testrunner Open DB Listening on port 9000... INFO 2012/11/09 19:21:06 test.go:95: Testing Booking example (github.com/revel/examples/booking) in dev mode Go to /@tests to run the tests. 1 test suite to run. AppTest PASSED 0s All Tests Passed.
You can also run a single test suite, or method within that suite, with a period-separated parameter:
$ revel test github.com/revel/examples/booking dev ApplicationTest $ revel test github.com/revel/examples/booking dev ApplicationTest.TestThatIndexPageWorks
In the console only a simple PASSED/FAILED overview by test suite is displayed. The tool writes more detailed results to the filesystem:
$ cd src/github.com/revel/examples/booking $ find test-results test-results test-results/app.log test-results/AppTest.passed.html test-results/result.passed
It writes three different things:
- The application’s stdout and stderr are redirected to
- One HTML file per test suite is written, describing the tests that passed or failed.
result.failedis written, depending on the overall success.
There are two suggested mechanisms for integrating this into a continuous build:
- Check the return code, which is 0 for a successful test run and non-zero otherwise.
- Require the presence of
result.successafter the run, or disallow the presence of
What Revel does is:
- Scan the test source code for types that (transitively) embed TestSuite
- Set the
revel.TestSuitesvariable to a list of those types in the generated main.go file.
- On demand, uses reflection to find all methods beginning with “Test” on the TestSuite types, and invokes them to run the test.
- Catches panics from bugs or failed assertions and displays the error helpfully.
Testing code is only built when the special
testrunner module is activated.
Areas for development
The testing framework could use the following improvements:
- Fixtures for populating a datastore with test data.
- Loggers that write to a file (instead of stderr / stdout) should also be redirected to
- See the godocs for