Exception handling and Very Simple unit testing ... ?

I’m at the point in my little Codea article series where I’m going to need to do Test-Driven Development things, building a suite of unit tests and running them all the time. I plan to build up that capability, thus showing that you can start simply for such things. (Otherwise, I would import some LuaTest framework.

I figure I can scarf test classes and test methods out of the _G table, but I’m wondering about fielding exceptions on the asserts. I can probably do without, but just wondering. Is there a more or less standard, and simple, way of fielding an exception and regaining control somewhere higher up in the execution stack?

Thanks!

Oh, and FYI, the articles are at http://www.xprogramming.com

You can use pcall to make a protected function call. This allows you to regain control after any errors in the call. Here’s a brief description: http://www.lua.org/pil/8.4.html — I was using this to implement “live coding” in the Codea-written-in-Codea experiment.

You might also want to take a look at the standard Lua debug library (http://www.lua.org/pil/23.html). Specifically the section on Hooks (http://www.lua.org/pil/23.2.html) might help.

Note that any generic frameworks you write can be included in other projects as dependent projects, by tapping the plus button in the editor and selecting them.

As I am reading this… vec2 is all lowercase

@Simeon. Reading these forums I am always learning new things… Not sure why I never noticed projects can be dependencies before.

thanks!

You’re not advertising your articles any more. Is anybody reading them?

Anyway, here’s a bug in the equal function which passes your insufficient test:


function Polyline.__eq(p1,p2)
    local a1 = p1.polyline
    local a2 = p2.polyline
    for i,p in ipairs(a1) do
        if (p[1] ~= a2[i][1]) then return false end
        if (p[2] ~= a2[i][2]) then return false end
    end
    -- not so good
    --return true
    -- better
    return #a1 == #a2
end

Or am I spoilering the next episode? Do you really want to tell us that the test intentionally doesn’t even cover the set of polylines you have used so far? Will there be a chapter on testing the tests?

After thinking some days about my critique I came up with the conclusion that I should do it better and not let unaware readers think that my version of equal is finished (the “better” comment was a hint that it is not the “best”).

The equal function can (and should) be improved further.

What am I doing better now than two days before? I’m telling you that there is still a trap in it.

Did I do my best? If I’d know …