[Cuis-dev] Tests

[Luciano Notarfrancesco]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220817/a2a2e069/attachment-0001.htm>