4 ms·

> I suspect OP writes great, "bug-free" code in the backend / systems domain, but I don't think their testing practice or anecdotes are applicable across the in

> I suspect OP writes great, "bug-free" code in the backend / systems domain, but I don't think their testing practice or anecdotes are applicable across the industry. I'll grant OP a Magic Cloak of Error Abolishment and an enchanted ring with +4 INT, +4 WIS, and +3 VARIABLE-NAMING... Regardless, what's the very first thing I'm gonna do when I inherit his project for support or further development? Start ripping it apart to add tests so that I can verify the behaviour of the system pre, and post, change. If that code base was tested before, even poorly, that means extending the tests and improving their web of assertions and I will be making positive changes to the code within hours. If that code base is untested then my maintenance activities will involve unsupported refactoring and WAGs about system behaviour once the new tests come online. Days of work will hamper the start of maintenance activities. From experience, it will also likley mean finding a bunch of previously hidden issues, bugs, and suspect behaviour that has to be re-analyzed and re-tested before maintenance work can begin in earnest. A strong feeling that something is "bug-free" does not tell me that everything works unchanged on a new platform/OS/architecture, or let me throw in a newly conceived corner case, or check some environmental oddity... If we start out with the premise that systems spend most of their lifetime in maintenance, preparing the system for maintenance activities and trying to eliminate risk in that delicate window make a lot of sense. Not for a lone developer who has a bunch of domain knowledge in their heads, but for teams where new individuals are exposed to new domains and code at the same time.

loup-vaillant 9y ago
> I'll grant OP a Magic Cloak of Error Abolishment and an enchanted ring with +4 INT, +4 WIS, and +3 VARIABLE-NAMING... Most of those come from my test suite. Without that, I'm back to -2 INT, -3 WIS, and a Cursed Cloak of Mistakes. I did let some bugs slip through the first time around… > what's the very first thing I'm gonna do when I inherit his project for support or further development? Start ripping it apart to add tests so that I can verify the behaviour of the system pre, and post, change. As far as Monocypher is concerned, I already did that. Test vectors, property based test, sanitisers, code coverage analysis, the works. The public interface is testable enough that you don't need to take apart anything to thoroughly test that library (it already is). Huge help with "making positive changes to the code within hours". This change to Blake2b for instance took me a few minutes to make and verify. https://github.com/LoupVaillant/Monocypher/commit/80ebf55307f689390d41c3c48eaeab157519bc7f https://github.com/LoupVaillant/Monocypher/commit/80ebf55307... > A strong feeling that something is "bug-free" does not tell me that everything works unchanged on a new platform/OS/architecture, or let me throw in a newly conceived corner case, or check some environmental oddity... It helps that Monocypher has zero dependency (not even the standard library), uses fixed size integers almost exclusively, compiles without warning as C and C++ with GCC and Clang, and that crypto code is abnormally straight line. > If we start out with the premise that systems spend most of their lifetime in maintenance I made sure Monocypher required next to no maintenance (I won't have the time for significant maintenance work). It's mostly a matter of size and scope.

loup-vaillant 9y ago

> I'll grant OP a Magic Cloak of Error Abolishment and an enchanted ring with +4 INT, +4 WIS, and +3 VARIABLE-NAMING... Most of those come from my test suite. Without that, I'm back to -2 INT, -3 WIS, and a Cursed Cloak of Mistakes. I did let some bugs slip through the first time around… > what's the very first thing I'm gonna do when I inherit his project for support or further development? Start ripping it apart to add tests so that I can verify the behaviour of the system pre, and post, change. As far as Monocypher is concerned, I already did that. Test vectors, property based test, sanitisers, code coverage analysis, the works. The public interface is testable enough that you don't need to take apart anything to thoroughly test that library (it already is). Huge help with "making positive changes to the code within hours". This change to Blake2b for instance took me a few minutes to make and verify. https://github.com/LoupVaillant/Monocypher/commit/80ebf55307f689390d41c3c48eaeab157519bc7f https://github.com/LoupVaillant/Monocypher/commit/80ebf55307... > A strong feeling that something is "bug-free" does not tell me that everything works unchanged on a new platform/OS/architecture, or let me throw in a newly conceived corner case, or check some environmental oddity... It helps that Monocypher has zero dependency (not even the standard library), uses fixed size integers almost exclusively, compiles without warning as C and C++ with GCC and Clang, and that crypto code is abnormally straight line. > If we start out with the premise that systems spend most of their lifetime in maintenance I made sure Monocypher required next to no maintenance (I won't have the time for significant maintenance work). It's mostly a matter of size and scope.