-
Notifications
You must be signed in to change notification settings - Fork 0
Testing plan
Unit testing is the most fundamental type of test that guarantee a unit of code function properly on its own. A unit test is the smallest testable part of an application. The main purpose is to test each function or component as soon as they are constructed. A unit test usually has one or more inputs and produces a single output.
Jest's main focus is on the simplicity of the provided functions and good support for large web applications. It works with web applications using Babel, TypeScript, Node.js, React, Angular, Vue.js, Svelte, and more. We chose Jest since it is an already established framework in the JavaScript ecosystem. In addition, their documentation is very clear and concise. Thus, the learning curve for developers would be less compared to other unit testing frameworks.
Some of the obvious benefits of using Jest for unit testing are:
- Improve the overall quality of the codebase.
- Ensure code reusability and reliability.
- Help seamless integration with other modules/components.
Learn more about Jest here: https://jestjs.io/
System testing (or end-to-end testing) is a common methodology used in the software development process to test if an application works well under product-like circumstances and with data that replicates live settings. The goal is to create a realistic experience that follows the steps of a real user scenario. To fully validate the system, testing should not only be performed on the system under test, but also on any other sub-systems that are related.
We chose Cypress because it is one of the most famous frameworks for system (end-to-end) testing in the JavaScript ecosystem. Compared to other similar frameworks such as Selenium or Splinter, Cypress takes much less time to learn and much less code to write in order to achieve the same results. In addition, Cypress also comes with extra functionalities to help developers observe the testing steps visually which is very convenient to pinpoint exactly where the test failed (if it happened).
Some of the "best-selling" features that are packed with Cypress:
- Time travel: Cypress can take snapshots as it runs the test suite.
- Debugging: Readable and traceable errors.
- Automatic waiting: Waits for commands and assertions before moving on.
- Spies, stubs, and clocks: Verify and control the behavior of functions, server responses, or timers.
- Network Traffic Control: Control, stub, and test edge cases without involving the server.
- Screenshots and videos: View screenshots were taken automatically on failure.
- Cross-browser Testing: Run tests within Firefox or Chrome browsers locally
Learn more about Cypress here: https://www.cypress.io/
An acceptance test is a formal description of certain behaviors of a system when some conditions have been met. An acceptance test is usually expressed as a scenario statement or a group of statements. Like unit tests, acceptance tests also have a binary result (either passed or failed). A passed acceptance test is the base indicator of a correctly implemented function/feature that met the requirements.
Using automated workflow is the best way to save the team's time on testing. Writing tests is often time-consuming, running them on the local machine every time a new function is added (repeatedly) can be tedious. This is the reason why we planned to continuously run tests and deploy code on the remote server. This way our team can save some more time to focusing on development.
Travis CI already comes with every Github project, it takes a minimal setup time in exchange for a full pack of benefits:
- Quick setup.
- Live build views.
- Pull request support.
- Pre-installed database services.
- Auto deployments on passing builds.
- Clean VMs for every build.
- Mac, Linux, and iOS support.
Learn more about Travis CI here: https://travis-ci.org/
Having an automated test runner is great. However, there are tests that may still be better tested manually by humans. Verifying the acceptance test cases for each user story would be one of those manual tasks that our team should carry out after completing a feature to ensure that it meets the specification of the software requirements.
Defects or bugs are unavoidable in any software project no matter how many test procedures have been carried out. It is very important to classify bugs properly so that the team can deliver the software product to customers in the shortest amount of time without losing effort in fixing unimportant bugs.
All the defects discovered should be marked with a classification as urgent / non-urgent / important / not-important so that the team can easily identify which defect should be worked on first to solve the most prioritized issue at the moment.
Each bug report should be created as a task in the project board with a "Bug" label. The description of the bug should follow the format below:
- Description:
- Steps to reproduce:
- Expected behavior:
- Actual behavior:
- Note:
- Probable cause: