brigadecore / brigadecore/brigade

implement a strategy for testing against a live database

Open
#1,965 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
2.4k
Forks
244
PR merge metrics
No merged PRs in 30d

Description

This issue is one of several that, collectively, will supersede #1811.

We need:

1. A new suite of tests that are separate from the unit tests (and the existing integration tests) and can be triggered separately from those other two using a new make target. These tests can assume the existence of a live MongoDB at some location like `localhost: 27017`. Go build tags can help to facilitate this separation and selective execution.

1. A new job in the CI/CD process that executes the above (`brigade.ts`). This shouldn't be too hard because Brigade jobs already support "sidecar" containers, so it's just one job composed of two containers where the "primary" executes the tests and the "sidecar" runs a live MongoDB to satisfy the tests' assumption that the database is available at `localhost: 27017`.

1. Individuals tests aren't the focus of this issue so much as developing the overall _strategy_, but clearly we'll have to build a few tests to prove it all works. (I suggest testing just one of the smaller "verticals" in the API, such as service accounts maybe.) The general approach should be:

1. Assume the DB server is already running.
1. Initializing a new DB on the running server for each test case will probably be advisable to avoid test cases impacting one another's results. i.e. Each test case needs to execute in its own little sandbox within the DB server.
1. Put the DB in known / starting state.
1. Execute the query or statement.
1. Make assertions on end state.

I will open separate issues for each of the "verticals" after we have proven we have a satisfactory strategy in place.

Contributor guide

Open the contributing guide

Research direction

Start by reading brigade.ts and the existing Makefile targets for unit and integration tests, then inspect how Go build tags could separate a live-database suite. A satisfactory result has a separately triggered test target, a CI job with a MongoDB sidecar, and a small vertical such as service accounts proving isolated database state and assertions.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, mongodb, typescript
Domain
ci-cd, databases, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.