The criteria I would apply are:
- Which framework is easiest to install for end users?
Or maybe better: Which is most likely to be already installed on the
system of the average Radiance user, even when not part of the
currently running build system?
* On unix
* on Mac (as far as different from other unixes)
* on Windows
- Which is easiest to maintain and to add test cases?
More specificly: Which has the shortest learning curve for the
average Radiance user before they can contribute tests?
- And last but not least, which has all the capabilities we need?
* Run a program with various arguments and input, and compare its
output against a prepared set of expected data.
* Eventually: Load a shared library and run similar tests on
individual functions (not easily possible with the current state
of librtrad, those pesky global variables once again).
-schorsch
Am 2016-03-16 22:28, schrieb Guglielmetti, Robert:
On 3/16/16, 3:02 PM, "Georg Mischler" <[email protected]> wrote:
That sounds like a lot of duplicate work...
Wouldn't it make more sense to maintain just one test suite, and
have either build system just invoke that?
Definitely a lot of duplicate work, you're right. I was thinking maybe
a
little too specifically about a particular testing framework (CTest in
my
case).
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
