Client-side unit testing?

[goldpbear]

The API has a lot of unit tests, but I noticed that the client has a few in place as well.

Have we ever tried running these tests? They seem kind of spare. Maybe we could expand on them? I think it would be nice to have tests for the dynamic form and multi datasets, and maybe tests for the way we handle layers and for the list view. Anything else?

[goldpbear]

Partial/in-progress list of client-side unit tests that would be useful to have at some point:

• General

  • Are all associated views and models (detail view, attachment view, layer view, activity view, etc.) created as expected when a new place is submitted? When a place is retrieved from the API?
  • Are all views deleted when a place is removed?

• Form data submission

  • Does submitted length, content, and format match returned length, content, and format for each form element this is not sanitized?
  • Do the length, content, and format of data submitted in place form views match the length, content, and format of data rendered by place detail views?
  • Are dangerous elements removed correctly by the sanitizer?
  • Does form submission work for both place forms and comments forms?
  • Are disallowed requests returning the correct http code?
  • Are allowed requests for authenticated users returning the correct http code?

• Editor

  • Does editor state update correctly on various types of input and UI changes? On place update? On place hide?

• Templates

  • Do templates produce the expected HTML output from various types of input? Do all the checks and if-else conditions behave as expected?
  • Do placeholder values work as expected? Do autocompletion values render as expected?

• Lazy loading layers

  • Does the map have the expected number of loaded layers given visibility settings?
  • Do newly visible layers get loaded correctly?

[modulitos]

I think we should start implementing UI testing as we convert our Backbone views to React components. With the React API, we should be able to test the cases enumerated above.

React components also have an API that's suitable for snapshot testing as well, using a tool like Jest. Note that we should still implement classic assertion-based tests, using React state/props, which Jest provides as well.

Here are some resources about Jest snapshot testing and how it can help us:

• https://benmccormick.org/2016/09/19/testing-with-jest-snapshots-first-impressions/
• https://facebook.github.io/jest/docs/en/snapshot-testing.html

Assuming that we continue with Jest, I think we should have the following goals:

• Implement snapshot testing for our components, at the proper granularity.
• Should be able to run jest --watch in development to have jest automatically test any changes as we make them. We can bind this to npm run watch:test.
• We should create a __tests__ dir next to the files that we are testing. Alternatively we can name all relevant test files with a *.spec.js or *.test.js convention.
• We might need to install babel-jest to enable our tests to use language features that are in other parts of our codebase (eg ES6 modules, async/await, etc)

Just to be clear, here are some non-goals:

• Jest has support for code coverage, but let's not include that in the first implementation.

Note that testing will be easiest to implement after merging our Place Detail and Place Form branches for the React port, since those branches are making significant updates to our React code. If we want to get started sooner, we can probably start bringing in testing by basing our branch off of the react-port branch.