Thank you for the link.

However, there are two violation of principles for effective unit
testing in the addon script.

 1. It should be easy to locate the failing test in the source code.
 2. It should be easy to get more information on the failure.

To elaborate them, I'll take the example from the wiki page at
http://www.jsoftware.com/jwiki/Addons/general/unittest

   unittest jpath '~addons/general/unittest/demo/two_test.ijs'
before bad
before ex2
before rplc
after rplc
Test: D:\Math\j602\addons\general\unittest\demo\two_test.ijs
bad: Error
|assertion failure: assert
|       assert'qq123'-:'qq123'rplc'qq';'zz'
ex2: OK
rplc: OK

1. We know that test_bad has failed. However, if the program told us
where the assert line lies(not the start of the verb test_bad) in the
source code, it would be more convinient to locate the place. All we
got from the current unittest program is, just the name of the test
case.

2. We know that the test case fails. However, we don't know full
information that is ready and very helpful for us to find the cause of
bug. If the failure result showed us what the actual value(the result
of 'qq123'rplc'qq';'zz') was against the expected value, we would be
at a more advantageous place.

Rectifying no. 2 isn't difficult with a new set of verbs, like should_match.

Rectifying no. 1 is difficult.

On Wed, May 6, 2009 at 8:11 PM, Oleg Kobchenko <[email protected]> wrote:
>
> Such Unit Test framework already exists as an addon:
>  general/unittest
>
>  http://www.jsoftware.com/jwiki/Addons/general/unittest
>
> The mentioned issues were addressed. In fact J has very rich
> introspection facilities, exception handling, and being
> interpretive help a lot.
>
> You might want to consider extending the framework with
> a GUI similar to JUnit/NUnit. The hierarchies of tests are
> in scirpts and further in folder structures, which can be
> discovered by traversing folder structure and naming
> conventions.
>
>
>
>
> ----- Original Message ----
>> From: June Kim <[email protected]>
>>
>> I am trying to make a unit-testing framework for J, in the lines of
>> the other standard star-unit frameworks, for example, like JUnit
>> http://en.wikipedia.org/wiki/JUnit
>>
>> However, I found the facilities for reflection and exception handling
>> in J is wanting compared to other languages like Java.
>>
>> ---------
>> sum=: +
>> mul=: *
>>
>> should_eq=: dyad :0
>>   :
>>   text=. ''
>>   if. -.x-:y do.
>>     text=. x ([,' -...@-: ',])&": y
>>   end.
>>
>>   text assert x-:y
>> )
>>
>> test_sum=: monad : 0
>>   10 should_eq sum/ 1 2 3 4
>>   10 should_eq sum/ 1 2 3
>> )
>> test_mul=: monad : 0
>>   24 should_eq mul/ 1 2 3 4
>>   6 should_eq mul/ 1 2 3 4
>> )
>>
>> all_test=: monad : 0
>>   test_sum''
>>   test_mul''
>> )
>>
>> all_test''
>>
>> ---------
>>
>> First limitation: I want to get the line number(in the script file
>> along with the file name) when there is a failure. How do I get this?
>> (13!:13 was a possible path but the line number there isn't the LN
>> from the top of the file)
>>
>> Second limitation: each test case should run independently from each
>> other. That means the failure in test_sum shouldn't stop running
>> test_mul. What is an easy and flexible way? (maybe making a gerund
>> array of test_sum and test_mul, and running through the gerund array
>> to execute each verb inside try, catch statement -- handling the
>> failure appropriately afterwards)
>>
>> Gathering all the verbs that start with "test_" wouldn't be that hard.
>> (reflection)
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
>
>
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to