Would it be safer to thoroughly delete these tests from the git history?
BTW, this fork was indeed active for a few months before the whole RIAA situation.
According to the DMCA, the entity that files a counter notice consents to jurisdiction of the US district court of their residence. If not a resident of the US, jurisdiction is the district where the service provider is located. Once a counter notice is filed, one cannot argue the law doesn't apply because of lack of jurisdiction.
Putting it in the README itself would be a far stronger signal of intentional malfeasance.
In the unit test... it's pretty clear the original developer's intent was simply to pick a video, and chose a trivially popular one (taylor swift), with likely no mind towards copyright (or its avoidance).
That is, the tool happens to be capable of the job, because it simply has purpose to download videos, with no awareness of copyright law.
Why is that? Why leave the -U option there?
Presumably, the update mechanism in this repo has been pointed to itself rather than upstream, and once you get binaries from it, you can resume updating them with -U.
If you want to write a unit test, then the test would mock the response from the server. You would have an expected sequence of expected requests and their responses. You would only be testing that you made the correct requests and, given the same response from the server, your code parsed it correctly and gave the expected outputs.
If the server bans your IP, or changes their response codes, your unit tests will still pass, as they should. Notification that the world has changed around you is not the purpose of a unit test. It is to allow you to feel confident of claims "I refactored the code and behavior is unchanged." or "I changed the behavior and this is how it has changed" or "I know that my code handles all known error codes from the server."
This is important when the world does change around you; as it lets you identify when that happens.
I recognize that test terminology is vague, and people will use competing definitions (I have seen 'functional', 'integration', and 'end to end' all used to describe non-unit tests, and I've seen each used to mean the others). I recognize this may seem as an exercise in pedantry. However, there is a valuable distinction to be made between tests that can be run deterministically, and tests that rely on the behavior of third parties outside of your control. These tests types will differ in terms of speed of execution, infrastructure setup (many test environments may not have network access, or may need special credential access)[1], reliability, and also, importantly, the proper response to a failure.
[1] Also, if you're doing mobile app development, you very much want to distinguish between tests that require a device and ones that don't. You will likely have multiple test classifications if you're doing mobile development.
The unit tests should only cover changes in the codebase... probing whether something serverside changed and whether the source material can still be downloaded can also be automated, but preferably not in a pipeline triggered by commits.
eg just enough to verify the content being pulled down was as expected, as would make sense for a video unit test
https://news.ycombinator.com/item?id=24878283
Now this submit is on the top of HN, and I still don't know why.
https://news.ycombinator.com/item?id=24450560 (199 points/104 comments)