[Pharo-dev] NB and OS specific tests

Stéphane Ducasse stephane.ducasse at inria.fr
Wed Aug 7 03:57:56 EDT 2013

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2013-08-07 at 9.13.38 AM.pdf
Type: application/pdf
Size: 99235 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20130807/78e9f169/attachment.pdf>
-------------- next part --------------

On Aug 7, 2013, at 9:49 AM, Torsten Bergmann <astares at 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 

More information about the Pharo-dev mailing list