[Cuis-dev] Tests

[Hernan Wilkinson]

Hi Luciano,
 maybe SUnit is not the framework you need for what you are doing... just a
thought. It looks like it is something too specific what you need and maybe
you need a special model for that.

Cheers!
Hernan.

On Wed, Aug 17, 2022 at 6:52 AM Luciano Notarfrancesco <luchiano at gmail.com>
wrote:

> Hi Hernan,
>
> Idea 1) is how I started some years ago, but eventually I moved on because
> it involves a lot of unnecessary work and it’s hard to maintain. Say you
> have 100 tests for matrices and you want to run them for 10 different
> rings, you’d have to write 1000 additional methods.
>
> Idea 2) is what I’d like to do instead of making concrete subclasses of
> the abstract tests. For that I’d have to write code that instantiates all
> test cases and sets all the parameters (like ‘scalars’ in the matrix
> example) and builds a TestSuite with all the tests. I guess I’ll try that.
> But I’d have to make a new TestRunner if I want to use the UI, and I’m sure
> I’ll find problems related to existing assumptions in the SUnit code (for
> example the problem that I tried to address in these emails, the assumption
> that a test ‘t’ can be copied by doing ‘t class selector: t selector’).
>
> I still think (IMHO) that TestCases should be able to run more than once,
> possibly changing the result, instead of creating new instances each time.
> Also the UI could be updated after running a test to reflect a change (for
> example to remove it from the failed or error lists when it passes, instead
> of finding the original test in the list with isSameAs: as it is done in
> TestResultWindow). I think lot of code could be improved and simplified. It
> would be easier if SUnit was a package, I could make an alternative package.
>
> Anyway, I’ll continue as I was doing, including those two methods in my
> tests package. And if someday we have SUnit in a package I’ll refactor it
> and simplify it.
>
> Cheers,
> Luciano
>
>
> On Wed, 17 Aug 2022 at 02:11 Hernan Wilkinson <
> hernan.wilkinson at 10pines.com> wrote:
>
>> Hi Luciano,
>>
>> On Tue, Aug 16, 2022 at 1:50 PM Luciano Notarfrancesco <
>> luchiano at gmail.com> wrote:
>>
>>> On Tue, 16 Aug 2022 at 21:56 Hernan Wilkinson <
>>> hernan.wilkinson at 10pines.com> wrote:
>>>
>>>> hmm just to clarify, cmd+t is not only for unit tests... it runs the
>>>> test that you are browsing. And cmd+y runs all the tests on the category...
>>>>
>>>
>>> Yes, but doesn’t work for tests that require some extra context. For
>>> example, say we have a MatrixTest with an instance variable ‘scalars’ that
>>> tests matrices over a given coefficients ring, and a test method
>>> testDeterminantProduct that creates two random matrices A and B and asserts
>>> that (A*B) determinant = (A determinant * B determinant). I cannot just run
>>> the test with cmd-t or cmd-y without specifying a ring of coefficients. I
>>> came up with two possible ways to implement concrete tests:
>>> 1) I make MatrixTest abstract (see TestCase class>>isAbstract) and make
>>> many concrete subclasses that implement #initialize and set ‘scalars’ to
>>> particular rings (for example a MatrixOverIntegersTest that sets scalars to
>>> Z). I’m currently doing this. The drawback of this approach is that I end
>>> up with lots of subclasses that only implement #initialize to set the
>>> scalars.
>>> 2) I don’t make subclasses of MatrixTest, and instead build test suits
>>> by instantiating MatrixTest for each coefficients ring I want to test and
>>> each test selector.
>>>
>>
>> Ok. If I understand correctly, the test is always the same code, is that
>> right? If so, I have two ideas, let me know if the make sense:
>> 1) to have in the same test suite (that is the subclass of TestCase), one
>> test method per configuration or ring of coefficients. For example:
>> test_xx_with_RingA
>> test_xx_with_RingB
>> and so on. Each of this test_xx_with_... send the same message that is
>> the real test that you parameterize with the ring.
>> Doing so you can run each test with is ring or all the tests that will
>> all the rings
>> 2) You can have one test with a collections of rings to run them all
>>
>> I think that having subclasses for each ring is an unnecessary
>> complexity, but I may not understand the problem correctly.
>>
>>
>>> Another way to achieve what I need is to copy the test case instead of
>>>>> creating a new one. Just need to implement
>>>>>
>>>>> TestCase>>copy
>>>>>     ^ self class selector: testSelector
>>>>>
>>>>> And in my subclasses I can make sure to copy all the additional state.
>>>>>
>>>>
>>>> That makes sense... and the #debug would do a copy, is that the idea?
>>>>
>>>
>>> Yes. I’d prefer if the system didn’t assume it can recreate a test case
>>> from the class and test selector alone. But for now I can continue
>>> without any changes to Cuis, it’s the simplest thing to do, I’ll continue
>>> including those two methods for TestCase in my package.
>>>
>>
>> Ok, let's keep things as they are. I think that what you need is too
>> specific and you have solved it satisfactorily.
>>
>>
>>>
>>>
>>>> Also I’d have to implement #isSameAs: in my subclasses
>>>>>
>>>>
>>>> Why?
>>>>
>>>
>>> Because two instances of MatrixTest for #testDeterminantProduct but with
>>> different scalars are different, for example one might test the determinant
>>> of matrices over the integers while other tests the determinant over the
>>> rationals (same testSelector, different scalars).
>>>
>>
>> ok, makes sense.
>> With option 1) I suggested above this would not be necessary
>>
>> Cheers!
>> Hernan.
>>
>>
>> --
>> <https://10pines.com/>Hernán WilkinsonSoftware Developer & Coach
>>
>> Alem 896, Floor 6, Buenos Aires, Argentina
>>
>> +54 11 6091 3125
>>
>> @HernanWilkinson
>>
>

-- 
<https://10pines.com/>Hernán WilkinsonSoftware Developer & Coach

Alem 896, Floor 6, Buenos Aires, Argentina

+54 11 6091 3125

@HernanWilkinson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220817/ac01c9a7/attachment.htm>