Doc: Updated info about unit tests and feature tests

CONTRIBUTING.md

@@ -23,13 +23,11 @@ Avoid listing multiple requests in one topic. One topic per request makes it eas
 
 Finally, when submitting a pull request, don't forget to [test your code](#unit-tests).
 
-# Contribute to the project
-
-## Contributing to Joplin's translation
+# Contributing to Joplin's translation
 
 Joplin is available in multiple languages thanks to the help of its users. You can help translate Joplin to your language or keep it up to date. Please read the documentation about [Localisation](https://joplinapp.org/#localisation).
 
-## Contributing to Joplin's code
+# Contributing to Joplin's code
 
 If you want to start contributing to the project's code, please follow these guidelines before creating a pull request: 
 
@@ -41,7 +39,7 @@ If you want to start contributing to the project's code, please follow these gui
 
 Building the apps is relatively easy - please [see the build instructions](https://github.com/laurent22/joplin/blob/master/BUILD.md) for more details.
 
-### Coding style
+## Coding style
 
 Coding style is enforced by a pre-commit hook that runs eslint. This hook is installed whenever running `npm install` on any of the application directory. If for some reason the pre-commit hook didn't get installed, you can manually install it by running `npm install` at the root of the repository.
 
@@ -49,44 +47,45 @@ For new React components, please use [React Hooks](https://reactjs.org/docs/hook
 
 For changes made to the Desktop client that affect the user interface, refer to `ElectronClient/app/theme.js` for all styling information. The goal is to create a consistent user interface to allow for easy navigation of Joplin's various features and improve the overall user experience.
 
-### Unit tests
+## Automated tests
 
-When submitting a pull request for a new feature or bug fix, please add unit tests for your code. Unit testing GUI changes is not always possible so it is not required, but any change in a file under /lib for example should be unit tested.
+When submitting a pull request for a new feature or bug fixes, please add automated tests for your code whenever possible. Tests in Joplin are divided in **unit tests** and **feature tests**.
+
+* **Unit tests** are used to tests models, services or utility classes - they are relatively low level. Unit tests should be prefixed with the type of class that is being tested - for example "models_Folder" or "services_SearchEngine".
+
+* **Feature tests** on the other hand are to test higher level functionalities such as interactions with the GUI and how they affect the underlying model. Often these tests would dispatch Redux actions, and inspect how the application state has been changed. The feature tests should be prefixed with "feature_", for example "feature_TagList". There's a good explanation on what qualifies as a feature test in [this post](https://github.com/laurent22/joplin/pull/2819#issuecomment-603502230).
 
 The tests are under CliClient/tests. To get them running, you first need to build the CLI app:
 
 ```sh
-npm run tsc # Build the .ts and .tsx files
-cd CliClient
 npm install
+cd CliClient
 ```
 
 To run all the test units:
 
 ```sh
-npm run test
+npm test
 ```
 
 To run just one particular file:
 
 ```sh
-npm run test -- --filter=markdownUtils # Don't add the .js extension
+npm test -- --filter=markdownUtils # Don't add the .js extension
 ```
 
 To filter tests. For example, to run all the test units that contain "should handle conflict" in their description:
 
 ```sh
-npm run test -- --filter="should handle conflict"
+npm test -- --filter="should handle conflict"
 ```
 
-If you get the error `Cannot find module '/joplin/CliClient/node_modules/sqlite3/lib/binding/node-v79-darwin-x64/node_sqlite3.node'`, you may need to run `npm rebuild`.
-
 ## About abandoned pull requests
 
-It happens that a pull request is started but not finished and despite our attempts to contact the contributor, we don’t hear from them again.
+It happens that a pull request is started but not finished and despite our attempts to contact the contributor, we don't hear from them again.
 
 In that case we will not merge the pull request, even if only small changes are missing. Our policy is simply to close the pull request. Why? Because an unfinished pull request essentially means giving us work and moving on. We would rather not encourage this behaviour.
 
 Also, please note that since we have spent time reviewing the pull request and proposing solutions, we reserve the right to re-use that knowledge to create a new pull request, potentially based on your changes.
 
-We’d much prefer that you complete the pull request though, so we’ll be sure to ping you a few times before that!
+We'd much prefer that you complete the pull request though, so we'll be sure to ping you a few times before that!