Iâve sort of padded around the edges of Traits, and decided to reread the papers and better understand them. One thing that occurs to me - if you want to test your traits, is the only suggested mechanism to test them in-situ with the classes that use them OR can you poof one up and test it by explicitly pumping in something that would represent âselfâ in its usage? Or is this the wrong question - and would you view Traits as a refactoring exercise - so you write tests for a concrete class first - and then extract them into a Trait keeping the tests running? This has the thorny side effect - which like inheritance, means that ultimately you have to test a BaseClass with all its concrete subclasses (so do you have to do the same with traits? As you may have overridden something you didnât intend?). I thought maybe the paper - âReusing and Composing Tests with Traitsâ might discuss this angle, but it doesnât cover it. Any thoughts/pointers? Tim
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
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
participants (2)
-
Damien Cassou -
Tim Mackinnon