Testing Flashcards
Learn Testing basics and advance concepts
What is unit tests?
Unit tests are your first line of defense against bugs. These tests are meant to run locally and verify the most fundamental bits of logic in your code.
Whether it be a function, a class, or anything else, unit tests are meant to test every feature/potential logical path. In fact, writing a unit test for every possible flow of your code is called 100% code coverage. Realistically, a good amount of code coverage will look something more like 80%. The more coverage you have, the more confidence you can have in your code when your unit tests pass.
What’s an integration test?
Integration tests check whether different chunks of code are interacting successfully in a local environment. A “chunk of code” can manifest in many ways, but generally integration tests involve verifying service/API interactions. Since integration tests are generally local, you may need to mock different services.
Effective and scalable codebases typically consist of many small pieces of code that do their job well, but how can we tell if they are successfully working together? Integration tests allow you to verify the “glue” between your services, i.e. API calls or database queries. This comes in handy as your codebase gets larger and includes more sophisticated interactions.
Integration tests aren’t quite as ubiquitous as unit tests, but there are many reasons to use them, such as:
- When you have services working together that were written by different people
- For testing your app’s database interactions, or between frontend/backend of your app
- Implementing “contract testing”, a.k.a verifying that your API is defined as expected
What’s an E2E test?
End-to-End tests, or E2E tests, are a way of verifying your code’s deployed behavior from a user perspective. You automate a user simulation that interacts with your system as a black box, so all that matters is whether the user’s actions correspond to the correct output in a timely manner. These tests are typically done in a dev or staging environment, in order to match the production user interactions as closely as possible.
E2E testing is like taking a practice exam – it’s the closest you can get to the real deal. Verifying that your code works in a near-real situation improves your confidence that your code will work in a real environment.
E2E tests are complex and difficult to implement. They are most common in production-grade code, so you can probably spare yourself the time on pet projects or schoolwork if manual testing is more efficient. In summary, use E2E tests when:
- There will be users aside from yourself
- You have enough infrastructure for a staging or dev environment
What describe means in testing?
describe(name, fn) creates a block that groups together several related tests.
This isn’t required - you can write the test blocks directly at the top level. But this can be handy if you prefer your tests to be organized into groups.
You can also nest describe blocks if you have a hierarchy of tests.
What test method means in testing?
test(name, fn, timeout)
Also under the alias: it(name, fn, timeout)
All you need in a test file is the test method which runs a test.
The first argument is the test name; the second argument is a function that contains the expectations to test. The third argument (optional) is timeout (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
If a promise is returned from test, Jest will wait for the promise to resolve before letting the test complete.
Even though the call to test will return right away, the test doesn’t complete until the promise resolves.
What expect means in testing?
expect(value)
The expect function is used every time you want to test a value. You will rarely call expect by itself. Instead, you will use expect along with a “matcher” function to assert something about a value.
The argument to expect should be the value that your code produces, and any argument to the matcher should be the correct value. If you mix them up, your tests will still work, but the error messages on failing tests will look strange.
What beforeAll means in testing?
beforeAll(fn, timeout)
Runs a function before any of the tests in this file run. If the function returns a promise or is a generator, Jest waits for that promise to resolve before running tests.
Optionally, you can provide a timeout (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
This is often useful if you want to set up some global state that will be used by many tests.
If beforeAll is inside a describe block, it runs at the beginning of the describe block.
If you want to run something before every test instead of before any test runs, use beforeEach instead.
What beforeEach means in testing?
beforeEach(fn, timeout)
Runs a function before each of the tests in this file runs. If the function returns a promise or is a generator, Jest waits for that promise to resolve before running the test.
Optionally, you can provide a timeout (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
This is often useful if you want to reset some global state that will be used by many tests.
If beforeEach is inside a describe block, it runs for each test in the describe block.
If you only need to run some setup code once, before any tests run, use beforeAll instead.
What afterAll means in testing?
afterAll(fn, timeout)
Runs a function after all the tests in this file have completed. If the function returns a promise or is a generator, Jest waits for that promise to resolve before continuing.
Optionally, you can provide a timeout (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
This is often useful if you want to clean up some global setup state that is shared across tests.
If afterAll is inside a describe block, it runs at the end of the describe block.
If you want to run some cleanup after every test instead of after all tests, use afterEach instead.
What afterEach means in testing?
afterEach(fn, timeout)
Runs a function after each one of the tests in this file completes. If the function returns a promise or is a generator, Jest waits for that promise to resolve before continuing.
Optionally, you can provide a timeout (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.
This is often useful if you want to clean up some temporary state that is created by each test.
If afterEach is inside a describe block, it only runs after the tests that are inside this describe block.
If you want to run some cleanup just once, after all of the tests run, use afterAll instead.
What Queries are in React Testing Library?
Queries are the methods that Testing Library gives you to find elements on the page. There are several types of queries (“get”, “find”, “query”); the difference between them is whether the query will throw an error if no element is found or if it will return a Promise and retry. Depending on what page content you are selecting, different queries may be more or less appropriate
After selecting an element, you can use the Events API or user-event to fire events and simulate user interactions with the page, or use Jest and jest-dom to make assertions about the element.
What different types of queries do in React Testing Library?
- Single Elements
-
getBy…: Returns the matching node for a query, and throw a descriptive error if no elements match or if more than one match is found (usegetAllByinstead if more than one element is expected). -
queryBy…: Returns the matching node for a query, and return null if no elements match. This is useful for asserting an element that is not present. Throws an error if more than one match is found (usequeryAllByinstead if this is OK). -
findBy…: Returns a Promise which resolves when an element is found which matches the given query. The promise is rejected if no element is found or if more than one element is found after a default timeout of 1000ms. If you need to find more than one element, usefindAllBy.
- Multiple Elements
-
getAllBy…: Returns an array of all matching nodes for a query, and throws an error if no elements match. -
queryAllBy…: Returns an array of all matching nodes for a query, and return an empty array ([]) if no elements match. -
findAllBy…: Returns a promise which resolves to an array of elements when any elements are found which match the given query. The promise is rejected if no elements are found after a default timeout of 1000ms.
-findBymethods are a combination ofgetBy*queries andwaitFor. They accept thewaitForoptions as the last argument (i.e.await screen.findByText('text', queryOptions, waitForOptions))
What test.each means in testing?
test.each(table)(name, fn, timeout)
Also under the alias: it.each(table)(name, fn) and it.each'table'(name, fn)
Use test.each if you keep duplicating the same test with different data. test.each allows you to write the test once and pass data in.
What describe.each means in testing?
describe.each(table)(name, fn, timeout)
Use describe.each if you keep duplicating the same test suites with different data. describe.each allows you to write the test suite once and pass data in.
What jest.useFakeTimers means in Jest?
jest.useFakeTimers(fakeTimersConfig?)
Calling jest.useFakeTimers() will use fake timers for all tests within the file, until original timers are restored with jest.useRealTimers().
You can call jest.useFakeTimers() or jest.useRealTimers() from anywhere: top level, inside an test block, etc. Keep in mind that this is a global operation and will affect other tests within the same file. Calling jest.useFakeTimers() once again in the same test file would reset the internal state (e.g. timer count) and reinstall fake timers using the provided options.
