3 ms·
I'd love to know how to test graphics and audio programs, frankly. TDD works very well for things with a defined input and output, including: 1. compilers 2. d
by voodootrucker 8y ago
I'd love to know how to test graphics and audio programs, frankly.
TDD works very well for things with a defined input and output, including:
1. compilers
2. databases
3. all web apps (output is the DOM)
In regards to the escape string, if there was a bug at exactly 15 characters, there must be a branch somewhere that isn't being hit, and it should be pretty easy using code coverage reports to find it, and generate the correct input sequence to exercise it.
When you get to fuzzing, you're hitting the edge of state-of-the-art. There is good research going on at automating some of that: http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/
- mdpopescu 8y agoWhat I do for graphics (never had to test audio programs) is to make the actual graphics code as simple as possible - no logic, very few lines: just take this thing and put it on screen. This way, I can inspect it visually, test it manually once and be reasonably certain that it will work. (Which can be incorrect, of course, but it's relatively rare. Lost a contract because of it once, so it can also be painful :D) Put all the logic in a class that can be tested and that returns something that can be used in the "get this, put it on screen" part mentioned above.