[Scons-dev] Testing non-core tools
Russel Winder
russel at winder.org.uk
Sat Jul 27 08:09:15 EDT 2013
Dirk,
On Sat, 2013-07-27 at 13:30 +0200, Dirk Bächle wrote:
[…]
> I think this would require a definition of what exactly entails the term
> "right paradigm". Also, calling for an "easier way" instinctively makes
> me ask: "For the users, or the developers?".
I think "user" and "developer" here is possibly a less important
distinction that in other situations since the developers are you and
whoever writing Python code, and the users are Python programmers
writing Python code.
> As long as there is a way to run tests for out-of-core Tools, and it's
> documented and reproducible for the user, it feels "right" to me.
>
> If you can think of a more advanced setup, or would like to talk about
> what exactly is annoying you, let's discuss it.
My irritant here is that the test SConstruct is not the same as would be
used in a real project. Given all SCons tests are effectively system
tests, I tend to prefer the code of the test being exactly the code the
"end user" (as in the person developing the project using SCons as build
tool).
If the test framework always added '.' to the tool search path when the
-e option was present then I suspect that it would get around my
problem.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : <http://two.pairlist.net/pipermail/scons-dev/attachments/20130727/5a7d8e09/attachment.pgp>
More information about the Scons-dev
mailing list