https://github.com/whiletruu/peers-against-humanity-backend
https://github.com/whiletruu/peers-against-humanity-backend
Last synced: 10 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/whiletruu/peers-against-humanity-backend
- Owner: WhileTruu
- License: mit
- Created: 2017-03-09T07:09:50.000Z (over 9 years ago)
- Default Branch: master
- Last Pushed: 2017-06-08T08:24:49.000Z (about 9 years ago)
- Last Synced: 2025-02-23T06:29:43.194Z (over 1 year ago)
- Language: JavaScript
- Size: 484 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Peers Against Humanity backend
## Table of Contents
- [Available Scripts](#available-scripts)
- [npm start](#npm-start)
- [npm test](#npm-test)
- [npm run build](#npm-run-build)
- [npm run database:rollback](#npm-run-database-rollback)
- [npm run database:latest](#npm-run-database-latest)
- [npm run database:seed](#npm-run-database-seed)
- [Environment variables](#environment-variables)
- [Installing a Dependency](#installing-a-dependency)
- [Running Tests](#running-tests)
- [Filename Conventions](#filename-conventions)
- [Command Line Interface](#command-line-interface)
- [Version Control Integration](#version-control-integration)
- [Writing Tests](#writing-tests)
- [Testing Components](#testing-components)
- [Using Third Party Assertion Libraries](#using-third-party-assertion-libraries)
- [Initializing Test Environment](#initializing-test-environment)
- [Focusing and Excluding Tests](#focusing-and-excluding-tests)
- [Coverage Reporting](#coverage-reporting)
- [Continuous Integration](#continuous-integration)
- [Deployment](#deployment)
- [Notes](#notes)
## Available Scripts
In the project directory, you can run:
### `npm start`
Runs the app, there's not really much difference between production and development modes, the only one being the PORT you specify in the environment variable.
### `npm test:unit`
Launches the test runner in the interactive watch mode and runs unit tests.
See the section about [running tests](#running-tests) for more information.
### `npm test:integration`
Launches the test runner in the interactive watch mode and runs integration tests.
See the section about [running tests](#running-tests) for more information.
### `npm run build`
Builds the app for production to the `build` folder.
See the section about [deployment](#deployment) for more information.
### `npm run database:rollback`
Rollback the last batch of mirations in the database matching your NODE_ENV.
### `npm run database:latest`
Updates the database matching your NODE_ENV to the latest migration.
### `npm run database:seed`
Adds required default data to the database matching your NODE_ENV.
## Environment variables
You can temporarily set environment variables by running the following command in your shell.
```
export ENV_VARIABLE_NAME=env_variable
```
Or to make the variable(s) permanent write those commands into your `.bashrc` or `.zshrc` or `.yourshellrc`
### `NODE_ENV`
Specifies the environment to run the, well, mostly db in. Might have some effect in app as well.
### `CONNECTION_STRING`
The database connection string.
### `SECRET`
A string used to sign user tokens with.
### `PORT`
The port to run the app on. If left unspecified, the default is 8080.
## Installing a Dependency
```
yarn add
```
## Running Tests
Peers Against Humanity backend uses [Jest](https://facebook.github.io/jest/) as its test runner.
### Filename Conventions
Jest will look for test files with any of the following popular naming conventions:
* Files with `.js` suffix in `__tests__` folders.
* Files with `.test.js` suffix.
* Files with `.spec.js` suffix.
The command `npm run test:integration` will look for files with `.integration.spec.js` suffix.
The command `npm run test:unit` will look for files with `.unit.spec.js` suffix.
The `.test.js` / `.spec.js` files (or the `__tests__` folders) can be located at any depth under the `src` top level folder.
Test files (or `__tests__` folders) should be placed next to the code they are testing so that relative imports appear shorter. For example, if `Yolo.test.js` and `Yolo.js` are in the same folder, the test just needs to `import Yolo from './Yolo'` instead of a long relative path. Colocation also helps find tests more quickly in larger projects.
### Command Line Interface
When you run `npm test`, Jest will launch in the watch mode. Every time you save a file, it will re-run the tests.
The watcher includes an interactive command-line interface with the ability to run all tests, or focus on a search pattern. It is designed this way so that you can keep it open and enjoy fast re-runs. You can learn the commands from the “Watch Usage” note that the watcher prints after every run:
### Version Control Integration
By default, when you run `npm test`, Jest will only run the tests related to files changed since the last commit. This is an optimization designed to make your tests runs fast regardless of how many tests you have. However it assumes that you don’t often commit the code that doesn’t pass the tests.
Jest will always explicitly mention that it only ran tests related to the files changed since the last commit. You can also press `a` in the watch mode to force Jest to run all tests.
Jest will always run all tests on a [continuous integration](#continuous-integration) server or if the project is not inside a Git or Mercurial repository.
### Writing Tests
To create tests, add `it()` (or `test()`) blocks with the name of the test and its code. You may optionally wrap them in `describe()` blocks for logical grouping but this is neither required nor recommended.
Jest provides a built-in `expect()` global function for making assertions. A basic test could look like this:
```js
import sum from './sum';
it('sums numbers', () => {
expect(sum(1, 2)).toEqual(3);
expect(sum(2, 2)).toEqual(4);
});
```
All `expect()` matchers supported by Jest are [extensively documented here](http://facebook.github.io/jest/docs/api.html#expect-value).
You can also use [`jest.fn()` and `expect(fn).toBeCalled()`](http://facebook.github.io/jest/docs/api.html#tobecalled) to create “spies” or mock functions.
### Using Third Party Assertion Libraries
We recommend that you use `expect()` for assertions and `jest.fn()` for spies. If you are having issues with them please [file those against Jest](https://github.com/facebook/jest/issues/new), and we’ll fix them. We intend to keep making them better for React, supporting, for example, [pretty-printing React elements as JSX](https://github.com/facebook/jest/pull/1566).
However, if you are used to other libraries, such as [Chai](http://chaijs.com/) and [Sinon](http://sinonjs.org/), or if you have existing code using them that you’d like to port over, you can import them normally like this:
```js
import sinon from 'sinon';
import { expect } from 'chai';
```
and then use them in your tests like you normally do.
### Initializing Test Environment
>Note: this feature is available with `react-scripts@0.4.0` and higher.
If your app uses a browser API that you need to mock in your tests or if you just need a global setup before running your tests, add a `src/setupTests.js` to your project. It will be automatically executed before running your tests.
For example:
#### `src/setupTests.js`
```js
const localStorageMock = {
getItem: jest.fn(),
setItem: jest.fn(),
clear: jest.fn()
};
global.localStorage = localStorageMock
```
### Focusing and Excluding Tests
You can replace `it()` with `xit()` to temporarily exclude a test from being executed.
Similarly, `fit()` lets you focus on a specific test without running any other tests.
### Coverage Reporting
Jest has an integrated coverage reporter that works well with ES6 and requires no configuration.
Run `npm test -- --coverage` (note extra `--` in the middle) to include a coverage report like this:
Note that tests run much slower with coverage so it is recommended to run it separately from your normal workflow.
### Continuous Integration
By default `npm test` runs the watcher with interactive CLI. However, you can force it to run tests once and finish the process by setting an environment variable called `CI`.
When creating a build of your application with `npm run build` linter warnings are not checked by default. Like `npm test`, you can force the build to perform a linter warning check by setting the environment variable `CI`. If any warnings are encountered then the build fails.
Popular CI servers already set the environment variable `CI` by default but you can do this yourself too:
### On CI servers
#### Travis CI
1. Following the [Travis Getting started](https://docs.travis-ci.com/user/getting-started/) guide for syncing your GitHub repository with Travis. You may need to initialize some settings manually in your [profile](https://travis-ci.org/profile) page.
1. Add a `.travis.yml` file to your git repository.
```
language: node_js
node_js:
- 4
- 6
cache:
directories:
- node_modules
script:
- npm test
- npm run build
```
1. Trigger your first build with a git push.
1. [Customize your Travis CI Build](https://docs.travis-ci.com/user/customizing-the-build/) if needed.
### On your own environment
##### Windows (cmd.exe)
```cmd
set CI=true&&npm test
```
```cmd
set CI=true&&npm run build
```
(Note: the lack of whitespace is intentional.)
##### Linux, OS X (Bash)
```bash
CI=true npm test
```
```bash
CI=true npm run build
```
The test command will force Jest to run tests once instead of launching the watcher.
> If you find yourself doing this often in development, please [file an issue](https://github.com/facebookincubator/create-react-app/issues/new) to tell us about your use case because we want to make watcher the best experience and are open to changing how it works to accommodate more workflows.
The build command will check for linter warnings and fail if any are found.
## Deployment
Install docker! :D
Make sure the docker service is running and then run ``docker compose up -d``, which should run the database container in the background. (You can check with ``docker ps``.)
`npm run build` creates a `build` directory with a production build of the app.
`npm run start` runs the server, which to function properly requires a database with tables and default data. The command requires the SECRET environment variable to be set, the CONNECTION_STRING variable is also needed, since the backend is not of much use without the connection.