Hello all
I would be grateful for hints on strategy in investigating test failures on upgrade. It is an area in which I have no experience; I can see some brute force approaches, but I suspect there are cleverer ways to do it.
I have OmniBase working successfully on Moose Suite 6.1 (Pharo 6.0, Latest update: #60541, 32-bit) on Windows 10. All the tests are green, and everything I have tried for my own data works well. To get a bit nearer to the state of the art, I tried to load OmniBase into a new 32-bit Pharo 7 image, created via Pharo Launcher a few days ago. I now have all tests green except one – named ‘testBTreeKeyLocking’. Since I am working in single-user mode, I do not expect to need key locking, so I could go on without worrying about it. But I am left with a nagging worry, and I would like to find out what is wrong. The test method has altogether 8 assert/deny statements, so I do not know where to start.
- Is there any obvious reason why the upgrade should make working code fail? Does P7 have a different compiler? If so, can I switch to an older compiler and see if it is that? (On P6 andP7, the code mentor complains that it should use ‘assert:equals:’ rather than ‘assert:’ and = , but that is true in all the other test methods.)
- Is there any easy way in the test framework to work out which assert/deny has failed?
- I could insert ‘self halt’ all over the place and use the debugger, or run the method in debug mode; would this be an approved way of doing it? The test suite creates and manipulates tiny databases; I am not sure whether there might be timing issues in stepping through the code.
Any help or suggestions gratefully received.
Peter Kenny
Locked
