Design Concept: Testing #38
Assignees
Comments
This was referenced Nov 21, 2018
Closed
arcticicestudio
added a commit
that referenced
this issue
Nov 24, 2018
Circle CI (1) is one of the most popular and proven CI providers that allows to automate pipelines from commit to deploy with a quick, safe, and scaled process. They support many languages and provide great and unique features like orbs (2), job orchestration, powerful caching, SSH or local builds for easy debugging and first-class Docker and GitHub integration (apps, hooks, etc.) support. The extensive and well-written documentations (3) make it easy to set up and configure it for the usage in projects. Circle CI has been used for almost all open source projects of Arctic Ice Studio and will be used as primary CI provider for _Nord Docs_ too. Before starting to run builds, Circle CI must be authorized on a per project basis to access the code on GitHub. After the process has been authorized (GitHub OAuth) the project will be added to the dashboard and required webhooks to listen for new Git events will be automatically set up. See the documentation about how to get started and add a project to the dashboard (4). NOTE: The latest config 2.1 features (5) are currently still in Beta Preview and must be enabled explicitly for each project via Settings -> Advanced Settings -> "Enable build processing (preview)"! See the "Enabling Build Processing" (6) documentation for more details. The Docker image of the CI container (7) will be the currently latest stable Node.js (8) LTS version `10.x.x` and the previous LTS version `8`. The `-browsers-legacy` tag suffix (9) can be used later on for end-to-end tests (GH-38) with Cypress (10). Next to Node.js these images currently include Chrome, Firefox, Java 8, and PhantomJS. To gather and upload all created coverage reports the "codecov/codecov" (11) Circle CI orb (12) which provides the `upload` command for easy integration into jobs and workflows. References: (1) https://circleci.com (2) https://circleci.com/orbs (3) https://circleci.com/docs (4) https://circleci.com/docs/2.0/first-steps (5) https://github.com/CircleCI-Public/config-preview-sdk/blob/master/docs/README.md (6) https://circleci.com/docs/2.0/build-processing (7) https://hub.docker.com/r/circleci/node/tags (8) https://nodejs.org (9) https://circleci.com/docs/2.0/circleci-images/#language-image-variants (10) https://www.cypress.io (11) https://circleci.com/orbs/registry/orb/codecov/codecov (12) https://circleci.com/docs/2.0/orb-intro GH-44
arcticicestudio
added a commit
that referenced
this issue
Nov 25, 2018
Circle CI (1) is one of the most popular and proven CI providers that allows to automate pipelines from commit to deploy with a quick, safe, and scaled process. They support many languages and provide great and unique features like orbs (2), job orchestration, powerful caching, SSH or local builds for easy debugging and first-class Docker and GitHub integration (apps, hooks, etc.) support. The extensive and well-written documentations (3) make it easy to set up and configure it for the usage in projects. Circle CI has been used for almost all open source projects of Arctic Ice Studio and will be used as primary CI provider for _Nord Docs_ too. Before starting to run builds, Circle CI must be authorized on a per project basis to access the code on GitHub. After the process has been authorized (GitHub OAuth) the project will be added to the dashboard and required webhooks to listen for new Git events will be automatically set up. See the documentation about how to get started and add a project to the dashboard (4). NOTE: The latest config 2.1 features (5) are currently still in Beta Preview and must be enabled explicitly for each project via Settings -> Advanced Settings -> "Enable build processing (preview)"! See the "Enabling Build Processing" (6) documentation for more details. The Docker image of the CI container (7) will be the currently latest stable Node.js (8) LTS version `10.x.x` and the previous LTS version `8`. The `-browsers-legacy` tag suffix (9) can be used later on for end-to-end tests (GH-38) with Cypress (10). Next to Node.js these images currently include Chrome, Firefox, Java 8, and PhantomJS. To gather and upload all created coverage reports the "codecov/codecov" (11) Circle CI orb (12) which provides the `upload` command for easy integration into jobs and workflows. References: (1) https://circleci.com (2) https://circleci.com/orbs (3) https://circleci.com/docs (4) https://circleci.com/docs/2.0/first-steps (5) https://github.com/CircleCI-Public/config-preview-sdk/blob/master/docs/README.md (6) https://circleci.com/docs/2.0/build-processing (7) https://hub.docker.com/r/circleci/node/tags (8) https://nodejs.org (9) https://circleci.com/docs/2.0/circleci-images/#language-image-variants (10) https://www.cypress.io (11) https://circleci.com/orbs/registry/orb/codecov/codecov (12) https://circleci.com/docs/2.0/orb-intro GH-44
arcticicestudio
added a commit
that referenced
this issue
Dec 13, 2018
To allow aliased imports in tests with Jest, ESLint must be aware of the "modulePath" field of the "jest.config.js" file. The installed ESLint plugin allows to define the path to the config file so ESLint can resolve used paths in tests. This is used for test util functions. Associated epic: GH-38 GH-64
3 tasks
arcticicestudio
added a commit
that referenced
this issue
Dec 13, 2018
References: (1) https://github.com/styled-components/jest-styled-components Associated epics: GH-38 Associated issues: GH-39 GH-76
arcticicestudio
added a commit
that referenced
this issue
Dec 13, 2018
This commit integrates jest-styled-components (1), a set of utilities for testing "Styled Components" (2) with Jest () that improves the napshot testing experience and provides a brand new matcher to make expectations on the style rules. This is the officially recommended library styled-components for Jest integration (3). Instead of storing the generated class names in snapshots it allows to track the actual CSS rules and attributes for better comparison what changed and if the change is even really related to the affected component. > Configuration To enable this features the package is simply imported in the test framework setup file defined in Jest's `setupTestFrameworkScriptFile` field (GH-39). > Custom Style Matcher The custom `toHaveStyleRule` matcher (4) is useful to test if a given rule is applied to a component. It will be added to the extended global `except` object when the main package file is being imported. References: (1) https://github.com/styled-components/jest-styled-components (2) https://www.styled-components.com (3) https://jestjs.io (4) https://github.com/styled-components/jest-styled-components#tohavestylerule Associated epics: GH-38 Associated issues: GH-39 GH-76
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This epic documents the design concept of the testing architecture of Nord Docs to ensure the project has a high quality as much as possible. Therefore a setup of stable and proven testing principles, libraries and tools will be used which are tailored for React based projects.
Most information in this document are based on fantastic references like the (in my option best) “Testing JavaScript” workshop by Kent C. Dodds who is a full-stack JavaScript engineer at PayPal (represents it on the TC39), a Google Developer Expert and teaches on egghead.io for many years. He is a important part of the React & JS open source community.
Next to the work on many testing libraries he's the creator of the react-testing-library and cypress-testing-library, that will be used for Nord Docs, (see Technologies section below) which grow fast in popularity and functionality while being simple and intuitive in usage. They encourage good testing practices by following avoiding to test implementation details of components and rather focus on making tests to give confidence for which they are intended and seen from the side of the user. The libraries are also recommended by the React core team itself in the official “Test Utils” docs and by Gatsby's Testing Guide (see section “Gatsby Setup” below).
A four-layer proven method for testing software
The Testing Trophy is a principle of the “JavaScript Testing” workshop and is a bottom-to-top professional method for testing web applications.
Technologies
Like described above, Nord Docs will use a stable and proven tech stack tailored for React that encourages best practices for testing. To do so the following chapters document which libraries and tools will be used and how they are set up to work together smoothly to provide the optimal developer workflow.
Jest
Jest is the official React testing library used by Facebook to test all JavaScript code including React applications.
Nord Docs will use Jest since it is officially recommended and developed by Facebook, is established and proven in the community and provides all required tools to simply and extensively test React components. It has a lot of support libraries and is flexible to be used with other libraries.
See the official website and docs for more information and guides about all functionalities.
All implementation details and requirements are documented and tracked in the corresponding issues:
react-testing-library
The react-testing-library is one of the awesome and most popular libraries for React testing, recommended by the React core team itself in the official “Test Utils” docs and by Gatsby's Testing Guide (see section “Gatsby Setup” below).
All implementation details and requirements are documented and tracked in the corresponding issues:
Cypress
For end to end tests Nord Docs will use the awesome open source project Cypress that provides a complete testing experience. It is easily and quickly to set up, can (like Jest for unit testing) execute in real time while coding, allows easy debugging in CI and locally and can record test data like screenshots and videos.
Cypress is a great tool to easily build end to end tests without the overhead required when using other outdated and no longer suitable solutions. It is also recommenced by many experienced and known JS developers including Kent C. Dodds who makes use of it and teaches it in his tutorials and workshops.
For more information check out the official website and docs.
All implementation details and requirements are documented and tracked in the corresponding issues:
-Gatsby Setup
Nord Docs is build with Gatsby (#25) and requires some changes compared to a “vanilla” or CRA React app, but like almost all aspects of Gatsby this is really well documented and explained with a work-through setup and usage guide in a large “Testing” chapter. These specific setup details described in the testing types/layer guides will be included in all other sections of this document.
All implementation details and requirements are documented and tracked in the corresponding issues:
Static Testing
The first layer of the “testing trophy” is the static testing which can catch typos and type errors when actually writing the code. This has already been set up and implemented in #15 using ESLint and React's prop types in #35. Also as described in both mentioned issues, it is considered to switch and refactor the code to a more advanced solution e.g. with typed languages like TypeScript or syntax extensions like Flow.
Unit Testing
The second layer of the “testing trophy” is unit testing which allows to verify that individual, isolated parts and components work as expected.
As a starting point the extensive Gatsby guide for unit testing will be used. Like documented in the technologies section above, Nord Docs will use the great react-testing-library which is combined with the also mentioned Jest library.
For more information check out the GitHub repository and Kent C. Dodds YouTube channel for testing tutorials and workshop recordings.
Integration Testing
The third layer of the “testing trophy” is integration testing to verify that several units work together in harmony. The setup is almost the same like for unit tests, but might include additional aspects like data fetching from APIs or integrations with third-party components.
End to End
The the fourth and last layer of the “testing trophy” is end to end testing (also called “E2E” or “functional testing”) that represents the user behavior in form of an automated test tool that clicks around the app and verifies it functions correctly. Like documented above, the awesome open source project Cypress will be used that provides a complete end-to-end testing experience.
The text was updated successfully, but these errors were encountered: