I think I am missing something, or something has changed and I failed to
notice.
I am trying to test a tool that is not in the SCons tree. The test needs
to put the tool into the fixture list so that the SConstruct of the
project under test can find it. First guess seems to be something like:
Hi Russel,
so far I always used the fixture methods from the testing framework with
a relative path, like this:
test.file_fixture('../../../__init__.py','site_scons/site_tools/qt4/__init__.py')
(example from the qt4 Tool tests). Doesn't this work for you?
There is also TestCmd::workpath(...)
Problem solved:
TestSCons.TestSCons()
causes the chdir() so by getting the getcwd() before that I am alright.
Is this "gotcha" documented anywhere?
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:
On 26.07.2013 19:30, Russel Winder wrote:
Problem solved:
TestSCons.TestSCons()
causes the chdir() so by getting the getcwd() before that I am alright.
Is this "gotcha" documented anywhere?
It is mentioned at
http://www.scons.org/wiki/DeveloperGuide/TestingMethodology
for the "Hello
...and please don't use the scons_test_framework repo for further
development (just got the notice that you cloned it). The current code
is in the normal SCons repo (runtest.py and QMTest).
Regards,
Dirk
___
Scons-dev mailing list
Scons-dev@scons.or
Dirk,
Thanks for getting back to me on this quickly, much appreciated.
On Fri, 2013-07-26 at 19:23 +0200, Dirk Bächle wrote:
> Hi Russel,
>
> so far I always used the fixture methods from the testing framework with
> a relative path, like this:
>
> test.file_fixture('../../../__init__.py','sit
On Fri, 2013-07-26 at 19:43 +0200, Dirk Bächle wrote:
> ...and please don't use the scons_test_framework repo for further
> development (just got the notice that you cloned it). The current code
> is in the normal SCons repo (runtest.py and QMTest).
OK problem to investigate. I had an ancient lo
On 26.07.2013 19:49, Russel Winder wrote:
On Fri, 2013-07-26 at 19:43 +0200, Dirk Bächle wrote:
...and please don't use the scons_test_framework repo for further
development (just got the notice that you cloned it). The current code
is in the normal SCons repo (runtest.py and QMTest).
OK proble
On Fri, 2013-07-26 at 19:55 +0200, Dirk Bächle wrote:
[…]
> Keeping all test scripts under a top-level folder "test", and adding
> "sconstest.skip" files where needed, should give you a start pretty
> quickly though.
So no more sconstest-XXX.py files?
--
Russel.
===
On 26.07.2013 20:00, Russel Winder wrote:
On Fri, 2013-07-26 at 19:55 +0200, Dirk Bächle wrote:
[…]
Keeping all test scripts under a top-level folder "test", and adding
"sconstest.skip" files where needed, should give you a start pretty
quickly though.
So no more sconstest-XXX.py files?
The
Dirk,
I have made a change to my canonical non-core tool package structure.
Instead of putting everything in __init__.py, I use a module of the same
name as the package and then import the relevant symbols in __init__.py.
This means that people can use the package or the module to taste.
--
Russ
On Fri, 2013-07-26 at 20:11 +0200, Dirk Bächle wrote:
[…]
> The runtest.py now detects any *.py file as test script, that's why the
> "sconstest.skip" (or even ".exclude_tests") exists and escapes this
> behaviour where needed.
> You can read a bit about this in the "Finding tests" section of
>
On 26.07.2013 20:27, Russel Winder wrote:
On Fri, 2013-07-26 at 20:11 +0200, Dirk Bächle wrote:
[…]
[...]
I have a test directory in the non-core tool package. If I run
"/runtest.py -a"
I get:
If you call the runtest.py for external tests, you have to specify the
"-e" option as wel
On Fri, 2013-07-26 at 21:36 +0200, Dirk Bächle wrote:
[…]
> If you call the runtest.py for external tests, you have to specify the
> "-e" option as well.
OK the -e has helped. Now I am back with:
1/1 (100.00%) /usr/bin/python -tt test/sconstest-issue_1.py
scons returned 2
STDOUT
Russel,
On 27.07.2013 11:45, Russel Winder wrote:
On Fri, 2013-07-26 at 21:36 +0200, Dirk Bächle wrote:
[…]
If you call the runtest.py for external tests, you have to specify the
"-e" option as well.
OK the -e has helped. Now I am back with:
1/1 (100.00%) /usr/bin/python -tt test/sconstest-is
Dirk,
[…]
>1.) Either add 'toolpath=["."]' to the environment definition, or
>2.) put the protoc.py in a default path, where it gets picked up
> automatically:
>
>test.file_fixture('../protoc.py','site_scons/site_tools')#
> untested!
1 works, I haven't tried 2 since 1 worke
Russel,
On 27.07.2013 13:00, Russel Winder wrote:
[…]
Does this help?
Yes, but… is this the right paradigm to get people writing tests for
non-core tools to use? I can become happy with "yes", but I just wonder
if there is an easier way.
I think this would require a definition of what exactly
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
Russel,
On 27.07.2013 14:09, Russel Winder wrote:
Dirk,
On Sat, 2013-07-27 at 13:30 +0200, Dirk Bächle wrote:
[…]
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
Dirk,
On 2013-07-27, at 13:30+0100, Dirk Bächle wrote:
> I don't want to appear nit-picky, but when you set up an SConstruct for a
> project that uses a locally packaged Tool module (like your protoc.py, in the
> top-level folder), you have to specify "toolpath=['.']" as well. ;)
Not not-pick
On 27.07.2013 15:51, Russel Winder wrote:
[...]
But the need to specify the -e to test non-core tool packages is already a
marker that they are being handled specially. Also from the above tool sources
are special structures and deserve special support. Given tests must run under
the test fram
21 matches
Mail list logo
