From: Mathias L. <mat...@da...> - 2005-12-30 18:45:27
|
Ho, ho ho.... I played around in the HEAD branch a cpl of nights ago with commenting out the main-method in app.cpp and duplicating most of it in another tree, resulting in the possibility of having a MusE-binary without gui and the possibility of doing lots of bad things to it!! I've felt for a long time that we're lacking a good test setup where it would be possible to create regression tests, get lots of debug output, etc. When testing things I feel that I'm entering the same debug printouts in the same places in the code, just to remove them when commiting. I'm wondering if it could be interesting to make it possible to build the application in test-mode. Despite all auto-confs horrible features it has the nice feature to be able to configure in a completely different tree. It would be possible to create an option that enables you to do ./configure --test-mode-build or something, which could result in g++ ..... -DTESTMODE and #ifdef TESTMODE sections in the code where lots of error-checking could be done, printouts etc that would just induce overhead in the regular binary. If this sounds interesting, and if I personally feel that this is actually worth it, would you prefer to have this features enabled in the --enable-debug mode or in yet another --test-mode option? /Mathias |
From: Werner S. <ws...@se...> - 2005-12-30 21:46:31
|
On Friday 30 December 2005 19:55, Mathias Lundgren wrote: > Ho, ho ho.... > > I played around in the HEAD branch a cpl of nights ago with commenting out > the main-method in app.cpp and duplicating most of it in another tree, > resulting in the possibility of having a MusE-binary without gui and the > possibility of doing lots of bad things to it!! I've felt for a long time > that we're lacking a good test setup where it would be possible to create > regression tests, get lots of debug output, etc. When testing things I feel > that I'm entering the same debug printouts in the same places in the code, > just to remove them when commiting. > > I'm wondering if it could be interesting to make it possible to build the > application in test-mode. Despite all auto-confs horrible features it has > the nice feature to be able to configure in a completely different tree. It > would be possible to create an option that enables you to do ./configure > --test-mode-build or something, which could result in g++ ..... -DTESTMODE > and #ifdef TESTMODE sections in the code where lots of error-checking could > be done, printouts etc that would just induce overhead in the regular > binary. > > If this sounds interesting, and if I personally feel that this is actually > worth it, would you prefer to have this features enabled in the > --enable-debug mode or in yet another --test-mode option? Hello Mathias, honestly the best test method i know of is inserting dedicated printf's into the code and to remove them again as early as possible. Sometimes i'm cheating and i only comment them out when i feel i will need them again in the near future. This sounds silly (and sometimes it is) but all alternatives i know of are much worse and boring. Many years ago i was instrumenting my code with a lot of debug stuff. Starting with assert's to a zoo of different debug macros, producing lots of debug output with different debug levels and debug types. All this is evil. Dont do it. Its a waste of time. It makes the code unreadable and unmaintainable. Read was Linus Torvalds thinks about this harmless looking assert macros and debuggers in general (sorry no link). He is right. It would be very nice to have some kind of regression tests and to more formalize testing. So its definitely worth to think about it and to try out some new things. So feel free to try out what you think is worth your time (and i would prefer another --test-mode option because i use MusE nearly exclusive with --enable-debug). My plan was to stabilize some of the internals of MusE and to transfer them to the AL and Awl libs establishing a more stable API. A test framework would be another program (not MusE) which exercises this libs/modules/units. Maybe the new available Qt4.1 QTestLib framework is useable for this (i have to try this out). A useful regression test would be a set of song files exercising all MusE features. But back to MusE debugging. Something fundamental is wrong with the current audio prefetch code. Some printf will show whats going on (i hope) :-) /Werner |
From: Mathias L. <mat...@da...> - 2005-12-30 23:29:22
|
fredagen den 30 december 2005 22.47 skrev Werner Schweer: > Hello Mathias, > > honestly the best test method i know of is inserting dedicated printf's > into the code and to remove them again as early as possible. > Sometimes i'm cheating and i only comment them out when i feel i will need > them again in the near future. This sounds silly (and sometimes it is) but > all alternatives i know of are much worse and boring. > Many years ago i was instrumenting my code with a lot of debug stuff. > Starting with assert's to a zoo of different debug macros, producing lots > of debug output with different debug levels and debug types. > All this is evil. Dont do it. Its a waste of time. It makes the code > unreadable and unmaintainable. Read was Linus Torvalds > thinks about this harmless looking assert macros and debuggers in general > (sorry no link). He is right. > > It would be very nice to have some kind of regression tests and to more > formalize testing. So its definitely worth to think about it and to try > out some new things. So feel free to try out what you think is worth your > time (and i would prefer another --test-mode option because i use MusE > nearly exclusive with --enable-debug). > > My plan was to stabilize some of the internals of MusE and to transfer > them to the AL and Awl libs establishing a more stable API. > A test framework would be another program (not MusE) which exercises this > libs/modules/units. Maybe the new available Qt4.1 QTestLib framework is > useable for this (i have to try this out). > > A useful regression test would be a set of song files exercising all > MusE features. > > But back to MusE debugging. Something fundamental is wrong with the > current audio prefetch code. Some printf will show whats > going on (i hope) :-) > > /Werner > Ah, we'll see what happens - about debug printouts they tend to grow quickly, resulting in need for tools for analyzing logs etc... The main idea is to be able to test things in an isolated environment (specific functions/features), and if possible create some tests for things that hopefully make it possible to spot things that might cause problems when it comes to different compiler versions etc. Since it's easier said than done to do these kind of things I'm simply beginning by collecting test-programs I'm writing over time, and see if it evolves over time. Personally, I like the idea of being able to run some kind of basic tests on things that I write, too check if there's anything seriously wrong with it, and then be able to run them again if I change anything. The burden of maintaining such code over time can be huge though.... :-) /Mathias |