Tracing the execution of scripts?
Michael B. Trausch
Fri Oct 27 14:17:28 CEST 2006
Jean-Paul Calderone wrote:
> In order of importance:
> 1) Write unit tests for your code. Keep writing unit tests until you have
> some that _don't pass_. Then fix your code so that they do. When you do
> further development, write the tests first, then implement the code that
> makes them pass.
Perhaps I could use some pointers on that. I have read the bits and
pieces that I have found regarding unit testing in the past, and I have
wrote "unit tests" for things that I have done, but mostly for pieces of
reusable code that interact with other programs.
And I still have to wrap my mind around the idea of test first, develop
later. It's fully possible that this works for many, but my (admittedly
few) attempts at that methodology have failed me. I have a problem
writing something without reference to look at while writing it -- so if
I am writing something, say, to test my AnsiTextCtrl, I would need to
look at the AnsiTextCtrl to see what methods and such I should be testing.
That having been said, I don't have the slightest clue how a unit test
would be written for something that is purely user oriented, anyway. I
was under the impression that unit tests were automated little tests
that required no user intervention to perform, right?
Actually, thinking about the idea of unit tests, I have found a few
resources online that generically talk about unit tests. Even the books
that I have read on programming talk about unit tests. However, all the
generic-ness with which the subject is approached makes my head spin.
(It does that a lot when I am trying to learn something new, by the way.)
> 2) Don't use threads. At least have a way to not use threads while you're
> debugging. Debugging with threads is very difficult. (Actually I'm not
> if you're using threads. If you're not, feel free to ignore this point.)
Fortunately, I am not. At least, I don't think I am, unless wxWidgets
uses them internally or something. Threading would make my head explode
at this point. I really am used to just pulling off simple, sysadmin
type things using massive subsets of languages to just "get things done."
> 3) Don't poll for network events every 20ms. If you have a sensible event
> loop you'll find debugging and testing much easier.
I don't know what you mean. I believe wxWidgets handles the looping.
And, as least, as far as I could tell with the documentation, the wx
networking API is not exposed to Python. The "event loop" that you are
describing is, I am assuming, the MainLoop which gets started for wx.App
> 4) Use an existing library instead of developing a new one.
I had looked for one, at least for the AnsiTextCtrl that I was using. I
never did find anything, so I assumed that it didn't exist.
> 5) (Only included so I don't look like a _complete_ jerk. If you get this
> far and you haven't fixed the problem yet, consider this a booby prize.)
I looked at this, and it made my head spin. I think it is just a touch
too early for me to be looking at things that I don't quite understand.
:-) I will take another look at it when I have been amongst the living
a little bit longer.
Thank you for the pointers here. At the very least, I have new ideas to
google around with (such as looking into "event loops").
As far as programming goes, I have done minor things with it, and web
applications (in PHP). I have never done GUI programming, or low-level
network programming, or anything like that before, and I tried doing
this project in C++ at first... and then said it wasn't worth it to me.
So, I'm not very well versed in many of the concepts -- I am literally
used to just writing tiny things (I can do very simple C programs, and
have been known to use PHP for help automating things) to make my life
easier, so this is the first real project that I have tried to work on.
The goal, of course, is to become a better programmer. But, I digress. :-)
More information about the Python-list