Testing

Testing BigBone

Overview

In this document, you will find details on the testing practices we apply, before a new version of BigBone is released to the public. In general, there are three main points that are relevant:

• Unit Tests
• Integration Tests
• Snapshot Releases

In the following sections, we will have a closer look into each of these. For software engineering people, most of this seems very normal / expected, therefore I'll focus on the integration testing part, which will be important if you want to run those tests on your system.

Unit Tests

For every class we write, we try to come up with some good unit tests. Actually, there's not much to say about unit testing, except that coverage is now as high as it should be and that we will improve this over time.

Integration Tests

To really verify the correctness of our library, we have built a set of integration tests. Those are run against specific versions of Mastodon that are launched locally on the developer's machine as a set of Docker containers managed by Docker Compose.

Test Setup

We provide Docker Compose setups for the versions of Mastodon we intend to support by the library. These Docker Compose setups can be found in the '/docker/' folder of our repository. There's a subfolder for every version of Mastodon we cover with integration tests. A folder name of 'v300' means that this is the Docker Compose setup for version 3.0.0 of Mastodon.

The integration tests are located in 'bigbone/src/integrationTest'. We provide a jUnit 5 test suite definition for every Mastodon version we cover. As an example: If you want to run all the integration tests for version 3.0.0 of Mastodon, just launch the 'V300TestSuite' class and that's it.

Same here, we have just started building the test suite, so there will be more tests coming as we move forward.

Running Integration Tests

So in order to run the integration tests for Mastodon 3.0.0, you have to do the following:

• Launch the Docker Compose setup for Mastodon 3.0.0 by switching into folder '/docker/v300' and run command 'docker compose build && docker compose up' from there. As soon as all the services are up, you can proceed with the next step.
• Launch the 'V300TestSuite' and check the results.

That's it!

Docker Compose Setup Insights

All the Docker Compose setups will launch the following services:

• PostgreSQL database
• Redis Cache
• Mastodon instance (incl. REST API) on port 3000
• Mastodon streaming API on port 4000
• Sidekiq task scheduler
• ElasticSearch
• Nginx reverse proxy

Also, there is a 'db-provision' Docker container launched during startup which performs some initial data loading into the PostgreSQL database directly.

After all the services have started up, you can reach the local Mastodon instance via 'https://localhost' in your browser.

Initially, two user accounts are provisioned, so you can login with them if you want:

'Username: [email protected]' 'Password: user1abcdef'

'Username: [email protected]' 'Password: user2abcdef'

The SSL certificate required to handle requests via https were created using mkcert:

mkcert localhost 127.0.0.1 ::1

Known Issues

Docker Desktop on Windows: ElasticSearch vm.max_map_count Error and Docker Desktop with WSL2 enabled

If you try to run the integration tests on a Windows machine using Docker Desktop with WSL2 backend enabled, you might end up having trouble making the ElasticSearch service work. If ElasticSearch throws an error complaining about the vm.max_map_count setting being wrongly configured, try to switch from the WSL2 backend to the Hyper-V backend. It will run slower, but at least it works.

Docker Complains About Unavailable Ports

When spinning up the Docker Compose environment, it can happen that Docker complains about ports that are unavailable. Something like this could be logged on the console:

docker : Error response from daemon: Ports are not available: listen tcp 0.0.0.0:1433: bind: 
An attempt was made to access a socket in a way forbidden by its access permissions.
At line:1 char:1

If this happen, the issue can usually be resolved when running the following commands and trying again after:

$ net stop winnat
$ net start winnat

Snapshot Releases

We publish snapshot releases to Maven Central every now and then to get some feedback from the public.