You're not wrong. Code was being written in Borland C++ for DOS (compiler circa 1992). The hardware has changed significantly in that space of time, and the old code has been hacked quite a bit. When it was first written, I'm sure nobody around here had even heard of automated unit testing.
There's something very South Yokshire about that phrase...
I wasn't thinking automated. I was thinking he followed this process: code it and if it compiles, throw it over the wall to integration.
Hopefully not a medical device. And I never did like C++ garbage collection. Always seemed like the lazy way out on memory management to me.
Anyway glad you found and fixed the root problem. Have a great day. Ed
That doesn't necessarily have to the case. Sometimes faulty code works correctly and may pass unit tests without a hitch. In that case the effects of the faulty code may only exhibits itself after something (OS, compiler, compiler settings, seemingly unrelated code, new library version...etc) has changed. Recently we had code that ran fine on Linux and passed all unit tests, but a debug build of the same code crashed on Windows. It turned out that a pointer was still being used after freed. On Linux the free operation left the contents of the freed memory intact. With the Windows debug library free operation overwrites the freed memory with a certain pattern, so the bug became visible.
Also unit tests do not necessarily find all errors. Even unit tests that have 100% code coverage (which can be quite a hard to achieve), don't necessarily cover all possible execution paths. Covering all execution paths is near impossible for non-trivial code, unless one resorts to (surprisingly expensive) advanced static code analysis tooling like Coverity.
Chances are you have written code that has bugs, which when discovered by someone else makes that person wonder if you did bother to test the code in the first place.
C++ doesn't have garbage collection.
What is your device and what software architecture (OS) you are using ?
ali
With white-box testing, achieving 100% coverage, can be achieved, but does it really pay off? Well written code should be immediately (or withing few seconds) understandable, in the context of having different execution paths.
Then there are code (or classes, functions, whatever) for which it is very difficult - or even impossible, or requiring significant infrastructure - to write unit tests with any sense (unit testing of accessors for example isn't probably very useful..). One might argue, that this problem of creating useful unit tests for some pieces of code, is an indication of bad design, but in pratice this happens quite frequently, for example with code doing network I/O.
This smells like a troll, and very much like it. I would bother..
-- Jyrki Saarinen http://koti.welho.com/jsaari88/
In shorter words: no amount of dynamic testing can ever prove a system to be bug-free.
Some will even go as far as to state "testing proves diddly-squat!", but that's a bit too strong --- testing can still prove errors, after all. It just can't prove correctness.
Lesson learned: do all your unit-test runs in valgrind!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.