Create a new branch on epochtalk/epochtalk
and update the
circleci-docker-compose.yml
images to use your branch's corresponding Quay
build.
(Be sure to change the tags back when you merge with master
.)
ex:
...
epochtalk:
image: quay.io/epochtalk/epochtalk:[your-branch]
...
epoch:
image: quay.io/epochtalk/epoch:[your-branch]
...
If you have changes in epochtalk/core-pg
, update
epochtalk/epochtalk/package.json
with the branch name.
epochtalk/epochtalk/package.json
...
"epochtalk-core-pg": "epochtalk/core-pg#[your-branch]"
...
Check CircleCI for the results when you push to your branch.
These instructions explain how to use docker
to test locally.
If you would like to test manually, check out the other README file: MANUAL_README.md
-
Use containers for the projects you are changing.
If you are only testing api test changes, skip this step!
If you are testing changes in any of the dependencies, build them with docker locally and specify the branch tag in
docker-compose.yml
.It may be useful to build the container and tag it with your branch name.
ex1: (testing an epochtalk/epochtalk branch)
/epochtalk/epochtalk
docker build -t epochtalk:[your-branch] .
/epochtalk/epochtalk-api-tests/docker-compose.yml
... epochtalk: image: epochtalk:[your-branch] ... epochtalk_seed: image: epochtalk:[your-branch] ...
ex2: (testing an epochtalk/epoch branch)
/epochtalk/epoch
docker build -t epoch:[your-branch] .
/epochtalk/epochtalk-api-tests/docker-compose.yml
... epoch: image: epoch:[your-branch] ...
-
Stop previous deployment
Stop and remove the old containers if you have run them previously.
docker-compose down
-
Build the
docker-compose
image for the api tests.docker-compose build
-
Run the tests by bringing up the
docker-compose
cluster.docker-compose up
This will run the tests and output the results to the console.
The tests are run by mocha
(node_modules/mocha/bin/mocha
) and written using
chakram methods and assertions.
Specifies the tests to run, and the order in which to run them.
Tests paths are defined here. The top level index will use these paths to require tests in a particular order.
Exposes routes as Node functions by calling chakram module methods
(ie. chakram.post
chakram.get
... etc.)
Contains convenience functions that use methods to perform operations, which are
useful for tests, but not necessarily accomplished by the exposed functions in
methods.js
.
This testing suite is set up with yeoman's testing guidelines in mind.
Generally speaking...
Expose the necessary api routes as Node functions in methods.js.
Tests go in the test directory and require ../methods.js
to call routes
as Node functions. Tests also require chakram
to do assertions.
Each describe
test checks one behaviour, with any required setup done in a
before
clause, then descriptions in it
clauses, followed by cleanup in
after
clauses.