I am impressed by #SQLite testing approach, breadth, methodology and investment:
https://www.sqlite.org/testing.html
It's very important that there are OSS projects that set such examples.
There is always something to improve, but I think nobody will object that that's good level of testing
-
-
Their fault injection approach is similar to systematic fault injection we use in syzkaller for
#linux kernel: https://lore.kernel.org/patchwork/patch/774420/ … That's the way for testing error paths. Lots of different fuzzers +1 Just one is never enough. Also continuous fuzzing on OSS-Fuzz.Prikaži ovu nit -
Measuring and knowing your test coverage +1 Lots of dynamic analysis +1 (though I am surprised to see Valgrind but not ASAN) Release checklists and tracking +1 (no "our release is all broken, but we did not even know")
Prikaži ovu nit -
Interesting note re static analysis (SA): "SA hasn't been helpful in finding bugs in SQLite. SA has found a few bugs in SQLite, but those are the exceptions. More bugs have been introduced into SQLite while trying to get it to compile without warnings than have been found by SA"
Prikaži ovu nit -
Though, the code base is clean of compiler warnings and _some_ static analysis warnings. Which makes sense.
Prikaži ovu nit
Kraj razgovora
Novi razgovor -
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.