http://stackoverflow.com/questions/29906723/delphi-xe8-bug-in-tlistt-need-workaround

http://stackoverflow.com/questions/29906723/delphi-xe8-bug-in-tlistt-need-workaround

Even by their standards, the defect identified in this question is shocking. Certainly this defect means that I could never release software built with XE8, as it stands.

Embarcadero have just re-implemented the collections in System.Generics.Collections to try to reduce executable size. However, it seems that their unit tests, if they even have any, are woefully inadequate. The new implementation is based around special casing for different element types and sizes. As such the testing needs to be designed to match that implementation.

So, unit tests that were appropriate for the previous implementation would have been inadequate for the new implementation, because they would not have covered all the branches of the new code. Is it possible that Embarcadero changed the implementation but did not change the tests to match?

And yes, I know that in an ideal world, a unit tests should not need to be modified to adapt to implementation changes. But the world isn't ideal. This is one of the best examples I've ever seen of of the fact that good unit testing can require in depth knowledge of the implementation.

In a recent road map, Embarcadero stated that they were going to work on QA/QC. Well, fixing old bugs is good. We like that too. But Embarcadero management, if you are listening, good QA/QC starts by not releasing defects to begin with. Yes, nobody ever manages a defect free release. But defects like this should never see the light of day. This code should never have been released. This code would not have been released if only you tested your code properly.

Marco Cantù  
http://stackoverflow.com/questions/29906723/delphi-xe8-bug-in-tlistt-need-workaround

Comments