> Quick Q: how do you find the location to make small changes like this when
> you fire up your development environment, and how do you test to make sure
> its the only thing to change?
In this case, I guess I believed I knew it, based on prior knowledge of the
code, i.e that all things to do with environment checking are in that
location. That said, I pretty much do a text search through the code. [Given
I reverted to Eclipse, Wings still is a bit flaky for me and I haven't found
a Python IDE I like, I don't have a better solution. Do you? I'd like to
find one.]
> How do you test a simple change like this works?
I run "gump" in the cron directory, and my local environment has:
GUMP_NO_CVS_UPDATE=true
GUMP_NO_SVN_UPDATE=true
GUMP_WORKSPACE=python\gump\test\resources\full1\tsws1
this causes a run of the test workspace data. Unfortunately (as your mail
made me realize) this isn't as good a test as I'd like. This is fine for a
lot of the 'mechanics' but not for a true full run. Basically, the data in
that workspace does not cover enough codepaths. [Clearly this has been
noticed w/ my 'multiple commits', so I can test on TEST.]
I've always struggled with testing Gump 'cos I don't have the most conducive
environment (no Linux, slow link, etc.) That said, I think I need to make a
better effort, and make a small workspace I can really work on.
BTW: This brings me back to the point you made about me not using unit test.
Interestingly, I consider myself a reasonably test infected kinda guy, but
you aren't wrong ... I'm not using them aggressively for Gump any more. I've
tried to consider why, and lack of IDE/(Pant = PyAnt ;-)scriptability and
all are factors. That said, I did really try. Python needs code coverage or
it is a walking time bomb of runtime errors, so I really wanted to...
I added the gump unit tests to the workspace, I added a script to try to run
tests, to run pychecker, etc. I suspect I simply stretched myself too thin,
and didn't get things right, but one big factor was 'environment'. There is
something (IMHO wrong) about Python launching other Python scripts, and not
using the PYTHONPATH for it, but having to know the path to the main script.
That caused some of these things to be harder than they ought be, and hence
fall by the wayside. [Take for example the fact of how nobody seems to have
a decent Gump command line interface. It isn't just us, the 4 or more people
who have tried, there is something (IMHO) hard about doing this right in
Python. If I could put my finger on it I'd blog about it in detail looking
for assistance, or better yet ... fixed it! ;-)]
Also, I think Gump problems always seemed to show up in runs, due to
metadata or environment or something, and not in simple Python code (other
than time bombs). I wrote unit tests, I wrote test environments, but I
always had a gap between this coverage and live. Even when Gump passed it's
unit tests, it still failed in runs. Perhaps the implementation was too
shallow, or something, but I found it too hard to write unit test for the
main/core parts. [One of the reason I went to runners/actors/etc. was to see
if I could get inside this aspect.] Perhaps I needed integration tests, but
those ended up best being the TEST environment.
In short think it is part Python, and part Gump's functionality, and part
individuals/time/focus as to why unit testing isn't playing a bigger role.
Basically, I love testing, I believe it is more critical for Python than
anything else, and I'm game to give it another shot.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
