Hi Igor, NB includes OS specific classes and examples that will/may require OS specific tests. IMHO it would make sense to change "NativeBoost-Tests" category into - "NativeBoost-Tests-Core" - "NativeBoost-Tests-Mac" - "NativeBoost-Tests-Unix" - "NativeBoost-Tests-Win32" while still keeping "NativeBoost-Tests" as one package. Later the package can be split easily (but only if necessary). So we have categories for the NB Core tests and OS specific tests similar to the other packages/categories. I would further provide common superclasses for OS specific tests, for instance TestCase subclass: #NBWin32SpecificTest instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'NativeBoost-Tests-Win32' and similar NBUnixSpecificTest and NBMacSpecificTest also. By overriding their #isAbstract method we can make their hierarchy only be runnable on the specific OS. So the OS specific Jenkins slaves will show broken OS specific code, Unix tests will not run on Mac, etc. Therefore we can control that the tests only run on the OS platform and find out when things fail. What do you think? I can do it when there is another minute. Thx Torsten
I like the idea. I tried to load the latest version of NativeBoost and I got at reload a nbBindingOf: error on a test so I found that totally confusing and I had to cancel my integration. Stef On Aug 7, 2013, at 9:49 AM, Torsten Bergmann <astares@gmx.de> wrote:
Hi Igor,
NB includes OS specific classes and examples that will/may require OS specific tests.
IMHO it would make sense to change "NativeBoost-Tests" category into
- "NativeBoost-Tests-Core" - "NativeBoost-Tests-Mac" - "NativeBoost-Tests-Unix" - "NativeBoost-Tests-Win32"
while still keeping "NativeBoost-Tests" as one package. Later the package can be split easily (but only if necessary).
So we have categories for the NB Core tests and OS specific tests similar to the other packages/categories.
I would further provide common superclasses for OS specific tests, for instance
TestCase subclass: #NBWin32SpecificTest instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'NativeBoost-Tests-Win32'
and similar NBUnixSpecificTest and NBMacSpecificTest also.
By overriding their #isAbstract method we can make their hierarchy only be runnable on the specific OS. So the OS specific Jenkins slaves will show broken OS specific code, Unix tests will not run on Mac, etc.
Therefore we can control that the tests only run on the OS platform and find out when things fail.
What do you think? I can do it when there is another minute.
Thx Torsten
I agree, except that as far as i know there is no platform-specific tests yet. On 7 August 2013 09:49, Torsten Bergmann <astares@gmx.de> wrote:
Hi Igor,
NB includes OS specific classes and examples that will/may require OS specific tests.
IMHO it would make sense to change "NativeBoost-Tests" category into
- "NativeBoost-Tests-Core" - "NativeBoost-Tests-Mac" - "NativeBoost-Tests-Unix" - "NativeBoost-Tests-Win32"
while still keeping "NativeBoost-Tests" as one package. Later the package can be split easily (but only if necessary).
So we have categories for the NB Core tests and OS specific tests similar to the other packages/categories.
I would further provide common superclasses for OS specific tests, for instance
TestCase subclass: #NBWin32SpecificTest instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'NativeBoost-Tests-Win32'
and similar NBUnixSpecificTest and NBMacSpecificTest also.
By overriding their #isAbstract method we can make their hierarchy only be runnable on the specific OS. So the OS specific Jenkins slaves will show broken OS specific code, Unix tests will not run on Mac, etc.
Therefore we can control that the tests only run on the OS platform and find out when things fail.
What do you think? I can do it when there is another minute.
Thx Torsten
-- Best regards, Igor Stasenko.
participants (3)
-
Igor Stasenko -
Stéphane Ducasse -
Torsten Bergmann