Thanks Damien - I’ll load up Nile and see what you guys did. I figured it might be the case that you have to create a TestTrait - although it does feel a bit like creating a TestConcreteClass to test an AbstractClass, which also feels a bit strange - and caused me (probably rightly so), to avoid inheritance and prefer delegation/composition.
Maybe its not so bad to have a TestTrait in practice - but I still wonder if there is a neat trick where it would be handy to “instantiate” one in test mode, where you specify a fake dependency and use that to right tests. Anyway - I’ll learn to crawl before trying to run ;) Tim On 9 Oct 2014, at 14:05, Damien Cassou <damien.cas...@gmail.com> wrote: > On Thu, Oct 9, 2014 at 2:17 PM, Tim Mackinnon <tim@testit.works> wrote: >> Any thoughts/pointers? > > I would tend to create one test trait for each application trait the > same way I create one test class for each application class. That > exactly what I did with the Nile stream trait-based library (there is > a journal paper about this library but I don't remember if it covers > the unit-test). The source code is available at > http://www.squeaksource.com/Nile.html. > > You can look at the unit tests for the collection library that are > entirely based on traits (but the collection library itself is not). > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >
