From cb824e6a930ca86b866bf26f41ed30e3e87e1997 Mon Sep 17 00:00:00 2001 From: Gage Date: Fri, 29 Mar 2019 07:26:55 -0600 Subject: [PATCH] Remove bsb dev setup suggestion This setup causes problems in most projects because (at least in create-react-app based ones, probably many others): - if you put `__tests__` folder at the root (outside of `src`) it will not be picked up by Jest. - if you put it in the `src` folder then bsb will try to double compile it and cause compiler errors. Not doing this configuration is fine because the test files are never bundled with the other files, even though it's not in dev mode. It also follows Create React Apps best practices of [putting test files next to the implementation ones.](https://facebook.github.io/create-react-app/docs/running-tests#filename-conventions) --- README.md | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index 41fa6fd..c49fea2 100644 --- a/README.md +++ b/README.md @@ -59,24 +59,12 @@ Then add `@glennsl/bs-jest` to `bs-dev-dependencies` in your `bsconfig.json`: "bs-dev-dependencies": ["@glennsl/bs-jest"] } ``` -Then add `__tests__` to `sources` in your `bsconfig.json`: -```js -"sources": [ - { - "dir": "src" - }, - { - "dir": "__tests__", - "type": "dev" - } -] -``` ## Usage -Put tests in a `__tests__` directory and use the suffix `*test.ml`/`*test.re` (Make sure to use valid module names. e.g. `_test.re` is valid while `.test.re` is not). When compiled they will be put in a `__tests__` directory under `lib`, with a `*test.js` suffix, ready to be picked up when you run `jest`. If you're not already familiar with [Jest](https://github.com/facebook/jest), see [the Jest documentation](https://facebook.github.io/jest/). +Put tests in a `__tests__` directory anywhere in the file structure (in create-react-app it should be anywhere nested under `src`). Use the suffix `*test.ml`/`*test.re` (Make sure to use valid module names. e.g. `_test.re` is valid while `.test.re` is not). When compiled they will be put in a `__tests__` directory under `lib`, with a `*test.js` suffix, ready to be picked up when you run `jest`. If you're not already familiar with [Jest](https://github.com/facebook/jest), see [the Jest documentation](https://facebook.github.io/jest/). -One very important difference from Jest is that assertions are not imperative. That is, `expect(1 + 2) |> toBe(3)`, for example, will not "execute" the assertion then and there. It will instead return an `assertion` value which must be returned from the test function. Only after the test function has completed will the returned assertion be checked. Any other assertions will be ignored, but unless you explicitly ignore them, it will produce compiler warnings about unused values. This means there can be at most one assertion per test. But it also means there must be at least one assertion per test. You can't forget an assertion in a branch, and think the test passes when in fact it doesn't even test anything. It will also force you to write simple tests that are easy to understand and refactor, and will give you more information about what's wrong when something does go wrong. +One very important difference from Jest is that assertions are not imperative. That is, `expect(1 + 2) |> toBe(3)`, for example, will not "execute" the assertion then and there. It will instead return an `assertion` value which must be returned from the `test` function. Only after the `test` function has completed will the returned assertion be checked. Any other assertions will be ignored, but unless you explicitly ignore them, it will produce compiler warnings about unused values. This means there can be at most one assertion per test. But it also means there must be at least one assertion per test. You can't forget an assertion in a branch, and think the test passes when in fact it doesn't even test anything. It will also force you to write simple tests that are easy to understand and refactor, and will give you more information about what's wrong when something does go wrong. At first sight this may still seem very limiting, and if you write very imperative code it really is, but I'd argue the real problem then is the imperative code. There are however some workarounds that can alleviate this: