Component unit tests

[AWolf81]

At the moment, we're having no component tests and that makes it difficult to make the coverage diff/patch of codecov pass.
We're having pretty good coverage at reducers & sagas but not at the components. That's why the overall coverage was just around 20%. See codecov for the current coverage.

So some things to discuss before this can be started:

• Which testing utility should we use? Enzyme or React-testing-library? Are there any other utilities we could consider? Decided to use Enzyme / see PRs [WIP] Component unit tests using react-testing-library #339 & Component unit tests enzyme #340
• What are the most important components to test? I'll pick some below ordered by importance (probably not complete):
  • CreateNewProjectWizard (pretty complex component as there are many parts involved - so no easy test to start with) (awolf81, after TaskRunnerPane & DevelopmentServerPane)
  • ProjectPage (awolf81)
  • DependencyManagementPane (awolf81)
  • DevelopmentServerPane (awolf81)
  • TaskRunnerPane (awolf81)
  • Sidebar (awolf81)
  • ProjectConfigurationModal (awolf81)
  • Initialization
  • ApplicationMenu
  • Modal (idoberko2)
  • Button (awolf81)
  • ProgressBar (will be used in LoadingScreen) (100% coverage)
  • EjectButton (awolf81)
  • BigClickableButton (awolf81)

We don't need to test every component e.g. the WhimsicalInstaller needs no component tests as it's something that could be easily replaced or disabled with-out affecting the work of the user.

List of components that I think are less important to be tested:

• WhimsicalInstaller (animation that's display during project building at final step of CreateNewProjectWizard)
• Spinner
• PixelShifter (just used for styling the UI)
• Planet (used by WhimsicalInstaller)
• Module (check usage)
• MountAfter
• NodeProvider (check usage)
• OnlyOn (check usage)
• Paragraph (check usage)
• ScrollDisabler (check usage)

Where I wrote check usage above it would be good to check where and if they're used. I haven't seen them in use but maybe I've missed them.

Describe the solution you'd like
After picking the testing utility we can start to work on this.

• Add a snapshot test for rendering
• Add tests for business logic of the component - basically have a look at each instance method & add a test.
• Check coverage (rule-of-thumb: Everything above 80% coverage is OK).

Some rules to follow - we should add them to the docs later

• Add snapshot tests just for things that are render with-out a lot of logic - rendering multiple snapshots for testing render logic is OK
• Prefer shallow over mount - use mount only if it includes Redux & you need the store or you're testing styled-components. Example of a connected component test (see ProjectPage.test)
• Test a single use-case/component at a time & avoid testing child components (shallow render helps here)
• If there is a handler in component jsx test trigger events it with simulate instead of using instance.clickHandler - so we're also testing that the handler is called correctly.
• Try to avoid testing implementation details (if possible with-out adding too much noise). A nice video about what I mean can be found here. (I'm not strictly following this as I think it's better to have a test - Todo: I need to create an example to show this.)
• Try to use TDD for new components. But it doesn't matter we can also write tests after we created the component code but we should add a coverage rule for every new feature PR.

Tips

• console.log(wrapper.debug()) can help debugging or use the built-in debugger in VS code
• const instance = wrapper.instance() can be used to test instance methods or life-cycle hooks.

[AWolf81]

I'm working on this.
I've picked the ProgressBar component as it's small and is easy to test.

I'll create two branches one with Enzyme and one with react-testing-library. I'll call them component-unit-tests-enzyme and component-unit-tests-testing-lib.

I've started with Enzyme. My WIP is pushed. Progressbar component test with 100% coverage is added.
I think I have to tests another component to see how tests with events are working.

I have some questions to my setup:

• I added a ignore to the coverage report to ignore all files with *.stories.js as we don't need to write test for stories, right? How are the docz files called later?
• We're having an index.js file inside of every component? Should we test it or is it OK to add it to the coverage ignore list? I think it's OK to ignore as we're following the style with the export default.

[idoberko2]

@AWolf81 are there any decisions regarding the testing library? I can give a hand with writing tests once it's decided.

[AWolf81]

@idoberko2 no, not decided yet.
What do you think? Which direction should we go?

I like the idea of not testing implementation details with testing-lib but I'm not sure and I tend to Enzyme as it's more mature & widely used.

Would be great if you could add an example in a testing-lib branch for another component.

[idoberko2]

@AWolf81, I knew enzyme from before and only heard about react-testing-library remotely. However, I also find their philosophy interesting and it does seem to be widely used (364K downloads a month, not near as much as enzyme, but substantial).
I will give it a try in the component-unit-tests-testing-lib branch and I'll let you know.

[AWolf81]

@idoberko2 I'm writing a test for the Button component - I'll add it to the todolist above.
Once you've started with a test, please let me know and I'll also add it.

[idoberko2]

@AWolf81 I'm starting off with the Modal component. I'll let you know how it goes.