On Saturday, November 1, 2014 10:01:48 AM UTC-7, Jason Merrill wrote:
>
>
> On Thursday, October 30, 2014 8:08:23 PM UTC-4, Sal Mangano wrote:
>>>>>
>>>>> I wanted a unittest framework that worked more like unittest in python
>>>>> (or xUnit in in other languages) so I
>>>>> wrote g...@github.com:smangano/JLTest.git. If you find it useful great. I
>>>>> am
>>>>> still new to Julia so if you find anything showing poor taste I am happy
>>>>> to
>>>>> get critique and/or suggestions for improvement. I'll try to add better
>>>>> docs but I think it is pretty self explanatory if you look at
>>>>> test/runtests.jl
>>>>>
>>>>>
>>>>>
> Re: macros, in places where you have macros that should take a function,
> or that will usually be called with a begin ... end block, you can often
> replace them with a plain old function and simplify the implementation.
> Julia's `do` syntax makes this especially easy. Same goes for macros that
> take a string and don't use it to generate code.
>
> Borrowing the example from the readme:
>
> using JLTest
>
> @testcase begin
> @casename "Mytest Tests"
>
> #Some code
> x = 0
>
> #Function to be called before each test (optional)
> @setUp () -> (x+=1)
>
> #Function to be called after each test (optional)
> @tearDown () -> (x=0)
>
> @test begin
> @testname "A Simple Test" #Name of test (optional)
> @assertEqual(x,1)
> end
>
> #more tests or code...
>
> end # end of test case
>
>
> Could become
>
> using JLTest
>
> testcase() do
> casename("Mytest Tests")
>
> #Some code
> x = 0
>
> #Function to be called before each test (optional)
> setUp() do
> x += 1
> end
>
> #Function to be called after each test (optional)
> tearDown() do
> x=0
> end
>
> test() do
> testname("A Simple Test") #Name of test (optional)
> @assertEqual(x,1)
> end
>
> #more tests or code...
>
> end # end of test case
>
>
> So concretely, I'm suggesting testcase, casename, setup, teardown, test,
> and testname could (should?) maybe all be functions instead of macros.
>
> The assertions are probably best left as macros, since they actually get
> something out of delayed evaluation (i.e. being able to print the original
> expresions when they fail).
>
I just took a look at the actual implementation, and it looks like part of
the reason for all the macros is to have a kind of dynamic scoping--i.e.
inside a testcase block there is an implicit current TestCase instance. I'm
curious if others have suggestions about how to manage dynamic scoping like
this (am I even using that term correctly?). It seems like something that
comes up in a number of places, and I'm not sure if there's a consensus on
it yet. One place I'm thinking of is in some of the plotting libraries,
where you want to build up a plot incrementally, so it's desirable to have
an idea of "the current plot".
