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.cassou@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