Section 1

Preview this deck

Snapshot Testing

Front

Star 0%
Star 0%
Star 0%
Star 0%
Star 0%

0.0

0 reviews

5
0
4
0
3
0
2
0
1
0

Active users

0

All-time users

0

Favorites

0

Last updated

6 years ago

Date created

Mar 1, 2020

Cards (15)

Section 1

(15 cards)

Snapshot Testing

Front

when you compare a data structure to an expected one. Snapshots are usually made to compare component representation data but they can also compare other types of data, like redux stores or the inner structure of different units in the application.

Back

Integration Tests

Front

Testing processes across several units to achieve their goals, including their side effects INTEGRATION TESTING is a level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units.

Back

Spies

Front

provide us with information about functions. For example, how many times were they called, in which cases, and by whom? Spies are used in integration tests to make sure that the side effects of a process are as expected. For example, how many times was a calculation function called during some process?

Back

Unit tests

Front

- Testing of individual units like functions or classes by supplying input and making sure the output is as expected: Unit tests are one of the reasons to use functional programming and pure functions as much as possible. The purer your application is, the easier you can test it.

Back

A/B tests

Front

A/B testing (also sometimes referred to as split testing) is the practice of showing 2 variants of the same web page to different segments of visitors at the same time and comparing which variant drives more conversions. Typically, the one that gives higher conversions is the winning variant, applying which can help you optimize your site for better results. Basically, help to determine if feature A is better than feature B, then A will be rolled out to everyone VMO / Adobe/ Optimizely

Back

Functional Tests (also known as e2e tests)

Front

Testing how scenarios function on the product itself, by controlling the browser or the website. These tests usually ignore the internal structure of the application entirety and looks at them from the outside like on a black box. Functional tests control browsers (7) and simulate user behavior on these environments (clicking, typing, scrolling etc...) and make sure these scenarios actually work from the point of view of an end user.

Back

code coverage reporting tool

Front

Code coverage is a measurement of how many lines/blocks/arcs of your code are executed while the automated tests are running. how much of your code is covered under tests. So, if you have 90% code coverage than it means there is 10% of code that is not covered under tests.

Back

Stubbing or dubbing

Front

replaces selected methods of existing modules with user-supplied functions in order to ensure expected behavior during the test. LIke sinon.stub(user, 'isValid').returns(true)

Back

Continuous Integration

Front

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. Maintain a code repository Automate the build Make the build self-testing Everyone commits to the baseline every day Every commit (to baseline) should be built Keep the build fast Test in a clone of the production environment Make it easy to get the latest deliverables Everyone can see the results of the latest build Automate deployment Tools: Jenkins Buildbot Travis CI Circle CI

Back

Mocks or Fakes

Front

used to fake certain modules or behaviors to test different parts of a processes. Sinon can, for example, fake a server to ensure offline, fast and expected responses when testing a certain flow.

Back

Visual regression testing tools

Front

can also be set up to verify that the different screens of your applications are ok visually by a smart comparison of screenshots. These screenshots are usually taken as part of your Functional Tests or by executing a separate session of browser automation.

Back

BDD

Front

Behavior Driven Development BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD. Behavior-driven development specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.[5][7][1] Borrowing from agile software development the "desired behavior" in this case consists of the requirements set by the business — that is, the desired behavior that has business value for whatever entity commissioned the software unit under construction.[5][1] Within BDD practice, this is referred to as BDD being an "outside-in" activity.[16] Other Vocab: USer Story, Narrative, Acceptance Criteria

Back

Putting it All Together - How do I start ?

Front

Start by choosing the testing structure and syntax (2) you like, assertion functions (3) library, and decide how do you want to run the tests (1). Some frameworks like Jest, Jasmine, TestCafe, and Cypress provide all of these out of the box. Some of them provide only some of the functionality and a combination of libraries should be used: (mocha + chai + sinon). We also suggest creating two different processes. One for running unit and integration tests and another one for Functional Tests. This is because functional tests usually take longer, especially when running the test suite on several different browsers. Think about when it's appropriate to run each type of test. For example: Unit + integration on every change, functional tests only before commits.

Back

TDD

Front

Test Driven Development It is designed to predict what your application is going to do, and it will try to ensure what kind of behavior it has It is created by creating test that will run from the beginning of the code, and the test will fail until the proper code has been built to produce the results of the test Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must: define a test set for the unit first; make the tests fail; then implement the unit; finally, verify that the implementation of the unit makes the tests succeed.

Back

Assertion functions

Front

used to make sure that tested variables contain the expected value.

Back