These issues are debatable. > 1. It should be easy to locate the failing test in the source code.
The output tells the script name and verb name, which are unique. If it is hard to find a place within the code of a single verb, the verb should be revised or split. > 2. It should be easy to get more information on the failure. assert 'qq123' -: 'qq123'rplc'qq';'zz' means "Assert that X equals Y'. The output clearly shows both the expected value and the expression. It does not really matter what was the wrong value--it should have been right. You don't want to mull over the output listing full of failures: you want to get it fixed quick and see all OKs. "should_match" could be considered feature creep. For examples of existing approach, see code snippet at http://en.wikipedia.org/wiki/Unit_testing#Design also the latest generation of xUnits: http://testng.org/doc/documentation-main.html#success-failure which uses standard Java "assert" mechanism. The thing to consider is how much additional value in relation to complicating the implementation does a new feature bring; in the meantime, are there more important features missing. However, it would be good to see and discuss some concrete proposals. > From: June Kim <[email protected]> > > 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 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 > >> > >> 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
