I don’t know why but for some reason I was hopeful to see unit tests in any of the repos. Searching “test” for that user doesn’t reveal any tests. :(
Even the digital property liberators/internet pirates don’t test their software. I feel like I’m on an island with a small population of test enthusiasts.
In this case, not so much, they block individual CDMs as they get leaked, but if you dump your own or find/purchase a non-public one, you're off to the races. They don't change the basic software APIs or crypto occurring.
However when it comes to something like this, it pretty much works or it doesn't and it'll be obvious one way or another when you run it. Writing unit tests for that is probably of limited value.
You’re right I should be more clear. I was more interested in automated test rather than manual/exploratory testing. Thanks for the opportunity to clarify my comment.
What's the best place to get started with testing? As a newbie brogrammer it's intimidating enough writing software that works, let alone suites to comprehensively test it. Is there a testing 'bible'?
I cannot recommend a book or an article, but just wanted to give an idea: automated testing is when you make a script do what a human tester would do. So maybe you should read about testing software in general. How test planning is done, how do you choose test cases.
You start with listing requirements (what a program/a class/a function is expected to do or not to do) and then write tests that verify that it is indeed so.
The easiest thing is writing unit tests. Pick a function, define requiremens and write a test for every requirement. If your code is not very modular and it is difficult to isolate a class or a function in order to test it, then maybe you should refactor the code first.
There are many deeply held beliefs that people have about testing, so I recommend reading many different takes on how to structure your testing approach. For the pragmatic python programmer, Brian's book is quite good as a starting place:
>Even the digital property liberators/internet pirates don’t test their software. I feel like I’m on an island with a small population of test enthusiasts.
Ultimately, what's the point. The tool either works, or it doesn't. Then you patch what doesn't work so it does work.
Heck even the Linux kernel isn't tested.
Unit tests are so management can have a good metric to sell code quality. I don't know any time unit testing has actually benefited shipping faster (which really is the only bottom line those above you care about)
> I don't know any time unit testing has actually benefited shipping faster
There's a lot of empirical research about this. A. Lot. Starting in the 80's, even. It's as close as it gets to empirically proven that software testing greatly reduces bugs and regressions, and accelerates delivery over the long term. It's not as clear if the acceleration is entirely freed up resources that would otherwise be spent fixing bugs, or if it also makes people develop faster. Also, it's pretty clear that Automated testing doesn't accelerate short or short term projects.
> I don't know any time unit testing has actually benefited shipping faster
It's of huge benefits to me when I have to make a small tweak (fix a bug, or add a new specific corner case) into an existing codebase that I didn't write and don't know very well.
Being able to make a small change and being confident that it will not send everything burning in hell.
This, and any code base of significant size is unknowable and starts to produce bugs naturally. Requiring tests and verifying minimum coverage are a few things you can do to control the death spiral.
I have worked on large systems devoid of tests. Not recommended. I literally witnessed multi-million dollar losses that would have been prevented by requiring tests.
Apart from the Linux Test Project [0], run by all the big Linux names, who regularly issue very detailed bug reports and usually patches as well, you mean?
And the test covers much less surface area than most manual tests.
For code that's expected to be stable for a LONG time - sure, write lots of good tests.
For code that breaks at someone else's whim, which has a small shelf life, or which has a large surface area, think really, really hard about whether the test is actually going to be worth it.
