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 <
[hidden email]> wrote:
> On Thu, Oct 9, 2014 at 2:17 PM, Tim Mackinnon <
[hidden email]> 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
>