be-gay-do-crimes
/
newpipe-documentation
mirror of https://github.com/TeamNewPipe/documentation
1
0
Fork 0
Code Issues Releases Wiki Activity

Apply suggestions from code review - 2

This commit is contained in:
opusforlife2 2021-11-27 15:23:42 +00:00 committed by GitHub
parent 81195776d7
commit c688e88ca6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/05_Mock_tests.md
View File

@ -1,17 +1,17 @@
# Mock Tests # Mock Tests
A web crawler is by nature dependant on the external service which it is crawling. A web crawler is, by its very nature, dependent on the external service which it is crawling.
In order to have a reliable CI pipeline, this external dependency needs to be removed. In order to have a reliable CI pipeline, this external dependency needs to be removed.
For this there is a system in place to automatically save the requests made to a service and their responses. For this, there is a system in place to automatically save the requests made to a service, as well as the responses received.
These can then be used in the CI pipeline to reliably test changes made to the Extractor and not have test failures due to API changes on the side of the service. These can then be used in the CI pipeline to reliably test changes made to the Extractor, and avoid test failures due to API changes on the side of the service.
## Multiple downloader implementations ## Multiple downloader implementations
There are multiple implementations of the abstract class `Downloader` There are multiple implementations of the abstract class `Downloader`
1. `DownloaderTestImpl` is used for running the test against the actual service. 1. `DownloaderTestImpl` is used for running the test against the actual service.
2. `RecordingDownloader` is used to save the request and response to the disk, thus creating the mock. 2. `RecordingDownloader` is used to save the request and response to a file, thus creating the mock.
3. `MockDownloader` is used to answer requests with the saved mocks. 3. `MockDownloader` is used to answer requests using the saved mocks.
### Usage ### Usage
@ -19,7 +19,7 @@ There are 2 ways to specify which downloader should be used.
First one is passing the `-Ddownloader=<value>` argument from the command line, where `value` can be one of First one is passing the `-Ddownloader=<value>` argument from the command line, where `value` can be one of
[DownloaderType](https://github.com/TeamNewPipe/NewPipeExtractor/blob/dev/extractor/src/test/java/org/schabi/newpipe/downloader/DownloaderType.java) [DownloaderType](https://github.com/TeamNewPipe/NewPipeExtractor/blob/dev/extractor/src/test/java/org/schabi/newpipe/downloader/DownloaderType.java)
. The main usecase is in the CI pipeline like this: `./gradlew check --stacktrace -Ddownloader=MOCK`. . The main use case is in the CI pipeline, like this: `./gradlew check --stacktrace -Ddownloader=MOCK`.
Other than that it can also be used to mass generate mocks by specifying which package should be tested. For example, if Other than that it can also be used to mass generate mocks by specifying which package should be tested. For example, if
one wanted to update all YouTube mocks: one wanted to update all YouTube mocks:
`gradle clean test --tests 'org.schabi.newpipe.extractor.services.youtube.*' -Ddownloader=RECORDING` `gradle clean test --tests 'org.schabi.newpipe.extractor.services.youtube.*' -Ddownloader=RECORDING`
@ -33,9 +33,9 @@ This is the main use case for when developing locally.
### Mock only tests ### Mock only tests
There are some things which cannot ever be tested reliably against an actual service. There are some things which cannot ever be tested reliably against an actual service.
For example tests for an upcoming livestream would fail, after the livestream was started. For example, tests for an upcoming livestream would fail after the livestream starts.
For this there is a marker interface `MockOnly` and a custom TestRule `MockOnlyRule`. For this, there is a marker interface `MockOnly`, and a custom TestRule `MockOnlyRule`.
It skips the tests in the CI pipeline if they are not run with mocks. It skips the tests in the CI pipeline if they are not run with mocks.
See `MockOnlyRule` for further details. See `MockOnlyRule` for further details.