Testing Flashcards

1
Q

Compare and contrast unit, integration and end-to-end tests.

A

A unit test is a test of a particular function and how well it works on it’s own. Integration tests test the interconnectivity of multiple functions, often testing a particular app feature and all it’s component parts at once. End-to-end test are more comprehensive and will test the entire application in order to evaluate the entire user experience across the app.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is a mock? What are some things you would mock?

A

a mock is basically a way of faking a certain function’s output in order to skip the actual running of that function. This can be useful when the function has already been thoroughly tested elsewhere and running it again in another unit test would be redundant or even slow down the test. Things that are often mocked are time intensive AJAX requests, reading and writing to files, or functions with random results (like Math.random).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is continuous integration?

A

continuous integration is a practice used by developers to continually test and merge work. The practice can be very usefull in creating a more robust application since no functionality will be built without unit and integration tests to make sure it works with the existing build.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What is TDD? What are some benefits and drawbacks?

A

TDD (Test Driven Development) is a practice in development in which the programmer will start by writing tests, then begin building out the application to satisfy those tests. This can be useful in assuring you know exactly what you want a program to do or not do and can keep you from making mistakes that may “break” other parts of an application. It tends to be a bit slower and can get a little excessive when there are more lines of test code than actual production code.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What are some ways to decide which code to test?

A

The easiest code to start with is the code that will be hit when everything goes as expected. This “happy” path can usually be tested pretty simply to see that there was a “successful” response from the server or output of a function. Then, it’s important to think of edge cases and test code that may be run when a user attempts to do things “incorrectly”. if there is really complex code that is likely to break, it should be tested more throughly, same for code that is more important or is used more frequently.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly