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 > sure > 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 derived objects? > > 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.) > http://divmod.org/trac/browser/trunk/Epsilon/epsilon/spewer.py > 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. :-) Thanks again! Mike -- http://mail.python.org/mailman/listinfo/python-list
