You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 21, 2023. It is now read-only.
Copy file name to clipboardExpand all lines: android/testing.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,11 +8,11 @@ The primary problem we try to solve with automated testing is preventing uninten
8
8
## Quick primer on automated testing
9
9
Automated tests are typically broken up into the following categories:
10
10
- 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
12
12
- Notable for being **the only test of the full system.** Tend to **run slowly**, **be fragile**, and **be difficult to debug**
13
13
- Integration tests
14
14
- 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
16
16
- Unit tests
17
17
- Tiny tests that test one single bit of functionality; they typically don't overlap
18
18
- 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].
113
113
## Best practices
114
114
This section is intended to be a non-exhaustive list of high-level guidelines (not rules!) when testing.
115
115
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
117
117
- 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
118
118
- For UI testing, disable animations: Espresso's handling of them is mediocre
119
119
- In addition to testing standard stuff like business logic and UI state, consider testing:
0 commit comments