Oleg-Sulzhenko/test-types

## test-types
End To End — Testing full blown user flows in the browser.
These tests consist of minimal mocks (i.e — you really are spinning up all the services that the user would be using).
Integration — Testing interactions between multiple services / components.
An “Integration test” is a bloated and often ambiguous term. For example, setting up a test that verifies interactions between multiple services (e.g — an api and a database) has overhead associated with it that is close to writing a full blown E2E test. On the other hand, writing a test that multiple react components work together in a redux environment has the complexity that is closer to a unit test. Read on to find out why ;)
Unit — Testing a single component / function in isolation.
A unit test is essentially testing input and output. It doesn’t get easier to reason about than this.
Some other types of testing:
Manual — A human being actually going through and verifying a flow on a real device.
Snapshot— Verifying a component’s rendered output.
Static — Testing pre compile-time (ESLint, TypeScript)
Cross Browser / Visual Regression —
Jest runs in node and uses jsdom which simulates a DOM environment as if you were in the browser. There are ways to test that code runs in a real broweser — (karma) but most cross browser JS concerns are a thing of the past now that we use modern frameworks and transpilers like Babel. CSS is a different story and services like saucelabs allow you to test that layouts are looking good across multiple browsers.
	End To End — Testing full blown user flows in the browser.
	These tests consist of minimal mocks (i.e — you really are spinning up all the services that the user would be using).
	Integration — Testing interactions between multiple services / components.
	An “Integration test” is a bloated and often ambiguous term. For example, setting up a test that verifies interactions between multiple services (e.g — an api and a database) has overhead associated with it that is close to writing a full blown E2E test. On the other hand, writing a test that multiple react components work together in a redux environment has the complexity that is closer to a unit test. Read on to find out why ;)
	Unit — Testing a single component / function in isolation.
	A unit test is essentially testing input and output. It doesn’t get easier to reason about than this.
	Some other types of testing:
	Manual — A human being actually going through and verifying a flow on a real device.
	Snapshot— Verifying a component’s rendered output.
	Static — Testing pre compile-time (ESLint, TypeScript)
	Cross Browser / Visual Regression —
	Jest runs in node and uses jsdom which simulates a DOM environment as if you were in the browser. There are ways to test that code runs in a real broweser — (karma) but most cross browser JS concerns are a thing of the past now that we use modern frameworks and transpilers like Babel. CSS is a different story and services like saucelabs allow you to test that layouts are looking good across multiple browsers.