[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: how to test private elements in a module
- From: "Thijs Schreijer" <thijs@...>
- Date: Mon, 24 Sep 2012 13:04:14 +0200
> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org]
> On Behalf Of Daniel Silverstone
> Sent: zaterdag 22 september 2012 12:12
> To: lua-l@lists.lua.org
> Subject: Re: how to test private elements in a module
>
> On Sat, Sep 22, 2012 at 11:55:10AM +0200, Thijs Schreijer wrote:
> > The best thing I could come up with is something like this at the end
> > of a module;
> [snip]
> > It's a small burden on production code and relies on a global
> '_TEST',
> > works perfectly well, just wondering if there is a better approach,
> > and if not, is there an accepted form of the '_TEST' global by
> another name?
>
> My approach tends to be similar. I tend to use environment variables
> instead, so that I can turn the functionality on and off during my
> tests and verify that overall functionality remains the same.
>
> Then I use special markers in the code, of the form:
>
> -- @@BEGIN_TEST_ONLY@@
>
> -- @@END_TEST_ONLY@@
>
> surrounding code I want removed during installation. My installation
> targets in my makefiles then remove code from between those markers
> during install.
>
> It's messy and relies on several moving parts, but it means I can unit-
> test the "local" code, I can test that nothing outside the module
> relies on the local code and I can remove the test code during
> installation so it's not doing environment variable lookups (and
> potentially polluting my published API/ABI) at runtime.
>
Your solution solves a different problem though, I'm in for testing where
you fix your code for distribution as runtime. I'm distributing through
LuaRocks, hence test and debug code is always included.
Makes me wonder whether LuaRocks actually has a notion of the type of
installation it does?
I could imagine several scenarios;
- runtime; all test and debug code removed possibly even compiled to
bytecode on installation
- user; all test and debug code removed, source code with documentation
installed
- developer; test and debug code remains, source distribution including
documentation and testfiles
anyway Thx for your input, my solution seems to be a common one then , so
for now it will do.