Conversation
|
Running |
|
Sooo, are there any opinions about this approach? Because i don't want to put more time into it if the approach is already not good. |
|
I missed this 20 days ago and I don't really have much time to dedicate to NewPipe currently, I may try to look at it the day after tomorrow. |
Stypox
left a comment
There was a problem hiding this comment.
I like this approach, it allows for expansion and is simple to migrate to. Thank you for your dedication :-D
...test/java/org/schabi/newpipe/extractor/services/youtube/YoutubeMixPlaylistExtractorTest.java
Outdated
Show resolved
Hide resolved
...test/java/org/schabi/newpipe/extractor/services/youtube/YoutubeMixPlaylistExtractorTest.java
Outdated
Show resolved
Hide resolved
extractor/src/test/java/org/schabi/newpipe/downloader/DownloaderFactory.java
Show resolved
Hide resolved
extractor/src/test/java/org/schabi/newpipe/downloader/MockDownloader.java
Outdated
Show resolved
Hide resolved
RecordingDownloader relies on the real downloader and saves the request/response pair into a json file. MockDownloader uses json files from above and mocks responses for specific requests.
…ables. If the system property 'downloader' is set that use that specific downloader. This is used from gradle by appending `-Ddownloader=ABCD to the command. ABCD is one of DownloaderType. The other variable is the static property `DEFAULT_DOWNLOADER` in DownloaderFactory, which can be easily changed as needed inside the IDE according to development needs`. Normal workflow would be to first use the recording downloader and afterwards only use mocks, if the requests are always staying the same.
This is needed so that a request is made for each test class when running multiple at once. This way RecordingDownloader records all necessary requests. This works as long as tests are run sequentially and not in parallel.
Only read those files in MockDownloader
2883e4a to
e82cb1e
Compare
|
@Stypox i rebased on top of dev. I will regenerate the mock files, when the pr is ready to be merged. edit: easier reviewing as in you only have to check the new commits. (after jsom generation) |
extractor/src/test/java/org/schabi/newpipe/downloader/RecordingDownloader.java
Outdated
Show resolved
Hide resolved
Can you put that info to a place where it can be found later? [To be honest, I don't know a good place for that] |
|
@TobiGr I added to the classes/methods themselves. Anywhere else it would just get out of date. Only thing thats missing is that CI jobs should use |
extractor/src/main/java/org/schabi/newpipe/extractor/services/youtube/YoutubeParsingHelper.java
Show resolved
Hide resolved
Stypox
left a comment
There was a problem hiding this comment.
Thank you, this now looks good to me. Do you still want to implement something else or is this ready @XiangRongLin ? @TobiGr I'll let you merge, since you also reviewed this PR.
|
I'll just recreate the json files later. Then it can be merged |
Stypox
left a comment
There was a problem hiding this comment.
Looking good to me, and the relevant tests succeed. Great :-D
My first draft to address the points abount mocking the responses in #481. Not yet merge ready, but before that i wanted to get some opinions on this type of solution.
RecordingDownloaderrelays request to the existing DownloaderTestImpl, but saves the request/response pair into a json file inside a folder specific to the test class. This should be done locally when the requests that are made by a test class change.MockDownloaderrelies on the json files created by theRecordingDownloader. PR/Push CI jobs should then use this downloader.DownloaderFactory.DEFAULT_DOWNLOADER-Ddownloader=ABCD, where ABCD is one ofDownloaderTypeDownloaderFactory. If none is giving it falls back to that one.Some sitenotes:
YoutubeParsingHelperholds a global state about client version and client key. The first test class that gets executed with theRecordingDownloadermakes a request and gets that request saved. Other test classes also need that request saved, but since the global state is then already initialized, that request won't be made. Currently I added that request as shared and add them to allMockDownloadersapache-commons-io can be removed if needed. Was needed to clear the directories beforeRecordingDownloaderfills them.gradle aggregatedJavadocs -Ddownloader=xyzworks because it won't work on windows due to file encoding. I only triedgradle extractor:test -Ddownloader=xyzIgnore the first (move package) and last commit (generated jsons) for easier diffs