Testing Traits?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Testing Traits?

Tim Mackinnon
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
Reply | Threaded
Open this post in threaded view
|

Re: Testing Traits?

Damien Cassou
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

Reply | Threaded
Open this post in threaded view
|

Re: Testing Traits?

Tim Mackinnon
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
>