Kenneth Love wrote: <cut> > That should teach me not to change working code at the same time I am > writing unit tests. Even so, I realize it won't be the last time I > do something so silly. Yes, I know about TDD's "write the test first", > but I'm not comfortable with the philosophy of these new fangled unit > tests yet. > <cut> I've been using python for about 3 years now, it was the first programming language I learned and I haven't done any other since (well that is if you dismiss sql and shell scripting on various platforms).
Though in my daily job I have some coding tasks, I do not see my self as a programmer since in my perspective a programmer is someone who can write good code regardless of the language. My code isn't any good, it is barely functional (so I really needed unit-test way of coding, for my own protection and not even because it gives more maintenance security for the project). But the funny thing that I have seen in the development scene is that writing tests first and code later is a lot easier when you have a technical specification to base it on. A technical specification is of course based on a functional design. A functional design is written on the base of the assignment and the scope definition. The scope and design can change in the course of the project but good practice is usually to do changes in another release. And that is what software change management and release management is for. Still there are tons of reasons why you shouldn't follow blindly the best practice, since best practice is founded on theory molded around the most occurring reality. And the only thing that I am absolutely sure of is that reality differs enough from person to person and situation to situation, that forcing the same practice to every person/situation is a guarantee for wasting time and energy. IMHO there are two extreme basic types of programmers, on the left are the ones that have a problem them self, solve it while happily hacking along the way, leaving the design part for a later stage, on the right are people that know beforehand on an almost bit level what a program is supposed to do, already have a design and aren't really that interested in the problem that their code should solve in the first place. Me I am a bit schizophrenic, I move in between of them, on a hourly base. So for me the reality is that I have a certain 'problem' I write some code with the built-in IDLE mostly following functional coding practice (since I still have to figure out how some stuff works in python). Then when I have a an idea what I am doing, I create a new project tree in subversion and write my technical specification (still having IDLE open to test some of the wild ideas that pop-up along the way). After that I open Eclipse/PyDEV and start working on the unit-test and follow from there, when the code is finished I check it in and branch it as 0.0.1. Sleep over it and probably refactor it later on because I didn't like some variables names and want to add some comments in the code or move out some code to other classes, etc. etc. The only problem is that I wish I was a bit more stable, because several times it has happend that I thought that the problem is a one-liner, so skipped the whole part after the figure-out-the-problem-code and used that what I have already written. Sometimes that works out well, but if it doesn't it always bites me hard. But all these are just experiences from my side, I have no idea whether I am right or not, but for me it seems to work, so don't take it as advice (I am not really the person to take advice from) but as a little 'story' along the way :-) -- mph -- http://mail.python.org/mailman/listinfo/python-list