Skip to content
This repository was archived by the owner on Feb 21, 2023. It is now read-only.

Commit 7a171cf

Browse files
committed
Issue #70 - review: Clarify typos, unclear text.
1 parent f63a07a commit 7a171cf

File tree

1 file changed

+3
-3
lines changed

1 file changed

+3
-3
lines changed

android/testing.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -8,11 +8,11 @@ The primary problem we try to solve with automated testing is preventing uninten
88
## Quick primer on automated testing
99
Automated tests are typically broken up into the following categories:
1010
- End-to-End tests
11-
- Black box tests that act like users: the system, they click the screen and assert what is displayed, typically following common user scenarios
11+
- Black box tests that act like users: they click the screen and assert what is displayed, typically following common user scenarios
1212
- Notable for being **the only test of the full system.** Tend to **run slowly**, **be fragile**, and **be difficult to debug**
1313
- Integration tests
1414
- Tests comprising of multiple parts of the system: they can modify and assert internal state
15-
- Compromise between end-to-end and unit tests. Tend to **run fairly quickly**
15+
- Compromise between end-to-end and unit tests. Tend to **run fairly quickly** since, unlike UI tests, they don't need to wait for UI changes
1616
- Unit tests
1717
- Tiny tests that test one single bit of functionality; they typically don't overlap
1818
- When written with non-overlapping assertions across tests, notable for **clearly identifying a single piece of broken functionality in a system.** Tend to **run quickly**.
@@ -113,7 +113,7 @@ See [this FFTV example of MockWebServer][mockwebserver example].
113113
## Best practices
114114
This section is intended to be a non-exhaustive list of high-level guidelines (not rules!) when testing.
115115

116-
- Don't depend on external factors, like the network, to ensure pour tests are always reliable
116+
- Don't depend on external factors, like the network, to ensure your tests are always reliable
117117
- For unit testing your UI, architect your application to separate your model from your UI, e.g. with architectures like MVP, MVVM, and MVI. Without consciously separating these parts of your application, it may be too difficult to test
118118
- For UI testing, disable animations: Espresso's handling of them is mediocre
119119
- In addition to testing standard stuff like business logic and UI state, consider testing:

0 commit comments

Comments
 (0)