According to Wikipedia
A test is an assessment intended to measure a test-taker's knowledge, skill, aptitude, physical fitness, or classification in many other topics. A test may be administered verbally, on paper, on a computer, or in a predetermined area that requires a test taker to demonstrate or perform a set of skills.
https://en.wikipedia.org/wiki/Test_(assessment)
How about the Dictionary (or Google's equivalent)
1. a procedure intended to establish the quality, performance, or reliability of something, especially before it is taken into widespread use.
https://www.google.com/search?q=what+are+tests
The reason(s) I would write a test
https://www.google.com/search?q=what+are+tests
High
Low
Advantages
Disadvantages
Advantages
Disadvantages
Advantages
Disadvantages
Advantages
Disadvantages
Advantages
Disadvantages
Advantages
Disadvantages
Advantages
Disadvantages
Libraries that are depended on should be thoroughly tested.
If you use an open source library that isn't tested as well as you would like, consider adding some to a PR for everyone's benefit.
Anything involving the safety of lives should be tested extensively from many different approaches.
Anything involving finances should be thoroughly tested and not just for security vulnerabilities. People tend to get upset when their money disappears.
The larger and the more complex the app the more you benefit from automated tests.
If you are just creating a site to learn a new tech don't worry about tests, unless that is part of learning the new tech.
If your app wasn't listed then it is probably in the middle somewhere.
We started with very few tests (read only what was pre-built in the scaffolding) until we had a somewhat stable API and we are now increasing our code coverage as we add or refactor features.
Tool: Cypress
Setup: Using a Docker instance of the database with pre-populated fields and a separate instance of the server. Writing the tests was pretty simple with Cypress. The setup did take a bit of work to get the data database and to keep it up to date. It is also kind of slow already.
import * as usersJson from '../../fixtures/users.json';
const API_URL = Cypress.env('API_URL');
const users = usersJson as any;
describe('User API: Fetch', () => {
it('if same user returns JSON, has hasCC field', () => {
(cy as any)
.loginByRequest(users.generic.email, users.generic.password)
.then((authToken: string) => {
cy.request({
url: `${API_URL}/user/${users.generic.id}`,
method: 'GET',
headers: { Authorization: authToken },
}).then(response => {
expect(response.body).to.be.an('object');
expect(response.body.email).to.not.be.undefined;
});
});
});
it('if not logged in returns JSON, does not have email', () => {
cy.request({
url: `${API_URL}/user/${users.generic.id}`,
method: 'GET',
}).then(response => {
expect(response.headers['content-type']).to.include('application/json');
expect(response.body).to.be.an('object');
expect(response.body.email).to.be.undefined;
});
});
});
Tool: Cypress
Setup: Using a Docker instance of the database with pre-populated fields and a separate instance of the server. Writing the tests was much simpler then expected with Cypress. Used the same database setup as used for the integration tests.
context('Handle Profile', () => {
beforeEach(() => {
(cy as any).loginByForm(users.generic.email, users.generic.password);
cy.get('#profile-heading').click();
});
it('can update the user profile information', () => {
cy.get('input[formcontrolname=firstName]').type(users.generic.firstName);
cy.get('input[formcontrolname=lastName]').type(users.generic.lastName);
cy.get('#user-profile-save-button')
.click()
.then(() => {
// we should have visible response now
cy.get('.toast-title')
.should('be.visible')
.and('contain', 'User Updated');
});
});
});
Many of the developers I read, listened to, or watched mentioned these as primary reasons why everyone has to write tests. I see these as secondary benefits that can be had other ways.
Your tests only cover bugs you already identified.
Your tests only cover potential bugs you already identified.