Skip to content

Latest commit

 

History

History
34 lines (18 loc) · 2.82 KB

Auto-tests.md

File metadata and controls

34 lines (18 loc) · 2.82 KB

[[TOC]]

TL/DR

  1. Run scripts/integresql/run-compose.bat (it will start a docker instance of IntegreSQL and Postgres that will be dedicated to tests).

Auto tests

Every backend functionality should be tested automatically. As a rule of thumb, we expect every HTTP method to have at least one integration test. This way we make sure that functionality generally works and is not completely broken :) Writing a suite of UnitTests is also encouraged.

Backend

Overview

We have 2 kinds of auto-tests:

  1. Unit-tests (MccSoft.TemplateApp.App.Tests). Here we test classes in 'isolation' from ASP.Net framework (i.e. http requests, model binding, deserialization, etc is not involved). These tests are fast and are best for fine-grained testing (testing every detail of a certain method/functionality).

  2. Component-tests (MccSoft.TemplateApp.ComponentTests) also known as Integration tests. These tests set up a real web-server (running in-memory) and we send real http requests to this server in tests. These tests test the whole request pipeline and you could express a full business scenarios with these kind of tests. They are a bit slower (compared to Unit tests), but give the maximum confidence that the system works. These tests usually are not changed during refactoring (i.e. if you split/move functionality between services, leaving API untouched).

    To send requests we use autogenerated client (based on Swagger definitions). See the article on how to generate them

#Frontend

You are encouraged to write a regular unit-tests for a functions in isolation using vitest (almost the same as jest). We usually test components via Storybook tests (see End-to-end tests section below)

End-to-end

We also have end-to-end tests (e2e folder). These test run a real browser (so you could actually see what's going on) and test the components in isolation (using storybook) or

You could get more details regarding Playwright or the structure of e2e tests

Backend code coverage

We strive to have 100% coverage on Controllers. (running tests with coverage significantly increase execution time: from 5mins to 20mins, so we no longer run coverage for every test run. probably we need a separate pipeline to run the coverage) To verify that you could download coverage.cobertura.xml files from build Artifacts (backend_coverage folder) and put it to tools/coverage/cobertura folder. Then run run.bat and check report folder to see the coverage. You could apply filters to see the coverage on separate files/classes. You will get reports like this: image.png