I'm currently doing the pretty-printer for pydev, and was thinking about the way I do things...
In the end, my 'usual modus-operandis' can vary somewhat depending on what I'm developing. Usually, I like to do things with tests up-front, as was the case for the most intricate parts of pyde, like code completion, code analysis...
On the other way, for things I consider simpler, and that usually have a good 'visual' feedback, such as populating the outline, I must say there's little testing I do... basically, I just 'wish' very hard that it will keep working. I guess I must be a 'good' boy, as usually these kind of wishes come true to me ;-)
Anyway, being 'test-infected', sometimes I wonder if I should test more these interactions... I basically think that it wouldn't do much difference for those simple cases, as the time I would need to spend writing those tests are probably higher than the time I spending fixing these bugs (pydev has a 'low' number of bugs for these things... and I'm not even sure if adding those tests would lower those numbers).
On the other way, I think that it would be 'almost' impossible to deal with the critical parts without it... Let's take code completion as an example. If someone takes a look at its implementation, you can see that there is a lot of dependencies among modules, and a lot of recursivity going in the way that tokens are resolved, and much more than once, when I was up to fix something I ended breaking something else that had a dependency on that, but thankfully -- I would say luckilly, but then I thought better... luck has nothing to do with it ;-) -- the tests kept that 'error-cycle' very short.
So far so good right? Anyway, I guess that the only 'bad' part about the 'test-infected' way of doing things is sometimes not taking the time to try to refine my initial design to make some things easier from the beggining... I mean, probably in the end, with the tests and refactoring, the result could be very close, but there's a 'middle-ground' somewhere between those, which I feel would be the optimal point.
On the other side, I must say that in pydev, many 'complicated' things, didn't even have that initial design, some because I didn't 'feel' like doing it and some because I had no idea where to start, so I just wrote a test and made it pass... and then other... and other ;-)
2 comments:
Is it planned to integrate a nice GUI-Runner like for JUnit http://www.onjava.com/pub/a/onjava/2004/02/04/juie.html?page=2 into PyDev?
Well, there are plans. There has been a previous attempt, but it still needs further improvements before being really available (for now, there is a simple replacement that can be used to run all unit-tests below a folder and sub-folders).
Cheers,
Fabio
Post a Comment