Probably obvious to the pros out there, but test-driven programming has really made a difference! I've been hacking away on some C++ code for a week now, and for the first time I have made a serious effort to write and run tests as an intergated part of the job. Some of the benefits: - One can't just write some code and expect it to be testable. One needs to break the code up in testable modules, which makes for a better overall design. - One can't get away by ostponing all those awkward limit cases; they come back and haunt you in no time. One has to deal with them up front. Which means the implementation is better. - One knows when one is finished, since the code apasses all the tests. Which means one avoids stress as one knows the exact state of the project. - As one tests blocks which depends on earlier blocks, one discovers bugs one made earlier (and thus, flaws in previous tests.) I just found and corrected a bug I wrote five days ago, due to a dependent module which failed a test. The Unit Test frameworks + post-build event configurations in the VS2005 IDE has really made the job a lot easier. Or at least more comfortable. Rune
OT? Test-driven programming
Started by ●September 15, 2008
Reply by ●September 15, 20082008-09-15
Rune Allnor wrote:> Probably obvious to the pros out there, but test-driven programming > has really made a difference! > > I've been hacking away on some C++ code for a week now, and > for the first time I have made a serious effort to write and run > tests > as an intergated part of the job. > > Some of the benefits: > > - One can't just write some code and expect it to be testable. > One needs to break the code up in testable modules, which > makes for a better overall design. > > - One can't get away by ostponing all those awkward limit > cases; they come back and haunt you in no time. One has > to deal with them up front. Which means the implementation > is better. > > - One knows when one is finished, since the code apasses all > the tests. Which means one avoids stress as one knows > the exact state of the project. > > - As one tests blocks which depends on earlier blocks, one > discovers bugs one made earlier (and thus, flaws in previous > tests.) I just found and corrected a bug I wrote five days ago, > due to a dependent module which failed a test. > > The Unit Test frameworks + post-build event configurations > in the VS2005 IDE has really made the job a lot easier. > Or at least more comfortable. > > RuneJerry, shall we let him in on a post 3rd generation language (aside to Rune - its newsgroup is abbreviated clf, LOL ;)
Reply by ●September 15, 20082008-09-15
On 15 Sep, 23:59, Richard Owlett <rowl...@atlascomm.net> wrote:> Rune Allnor wrote: > > Probably obvious to the pros out there, but test-driven programming > > has really made a difference!...> Jerry, shall we let him in on a post 3rd generation language > (aside to Rune - its newsgroup is abbreviated clf, LOL ;)Well, that a tool *exists* isn't sufficient for it to be useful; it needs to be *available* as well. Ah, and users need to be able to, well, use it. It might well be the case that you two oldies know these things from way back when. I've been making waves for a couple of years now by showing computer laypeople tricks I learned under UNIX decades ago, but this time applied in the windows world. Simple stuff like 'grep' and 'ls > regexp.' Hardly new or Nobel prize material, but it makes a certain impression on people who only knows the Windows GUI. Rune
Reply by ●September 15, 20082008-09-15
Rune Allnor <allnor@tele.ntnu.no> wrote in news:3e4a5aef-3e3e-4a2b-8b1e- 22efb12bc77b@f36g2000hsa.googlegroups.com:> - One knows when one is finished, since the code apasses all > the tests. Which means one avoids stress as one knows > the exact state of the project.This suggests that one knows what all the tests are before one starts programming. Definitely the way to go, but not always the way things are done. -- Scott Reverse name to reply
Reply by ●September 15, 20082008-09-15
Rune Allnor wrote:> Probably obvious to the pros out there, but test-driven programming > has really made a difference! > > I've been hacking away on some C++ code for a week now, and > for the first time I have made a serious effort to write and run > tests as an intergated part of the job.Unfortunately, even if all parts are working, that does not mean that the whole thing is working. There are also the compiler, the operating system and the hardware issues. VLV
Reply by ●September 15, 20082008-09-15
Rune Allnor <allnor@tele.ntnu.no> writes:> [...] > Or at least more comfortable.Real men use gnumake. -- % Randy Yates % "Rollin' and riding and slippin' and %% Fuquay-Varina, NC % sliding, it's magic." %%% 919-577-9882 % %%%% <yates@ieee.org> % 'Living' Thing', *A New World Record*, ELO http://www.digitalsignallabs.com
Reply by ●September 15, 20082008-09-15
Rune Allnor wrote:> On 15 Sep, 23:59, Richard Owlett <rowl...@atlascomm.net> wrote: > >>Rune Allnor wrote: >> >>>Probably obvious to the pros out there, but test-driven programming >>>has really made a difference! > > ... > >>Jerry, shall we let him in on a post 3rd generation language >>(aside to Rune - its newsgroup is abbreviated clf, LOL ;) > > > Well, that a tool *exists* isn't sufficient for it to be useful; > it needs to be *available* as well. Ah, and users need to be > able to, well, use it. > > It might well be the case that you two oldies know these things > from way back when. I've been making waves for a couple of years > now by showing computer laypeople tricks I learned under UNIX > decades ago, but this time applied in the windows world. > > Simple stuff like 'grep' and 'ls > regexp.' Hardly new or Nobel > prize material, but it makes a certain impression on people > who only knows the Windows GUI. > > RuneLOL and possibly just made IDIOT of myself Due to time zones I *presumed* Jerry would respond before you saw my post Your post was a list of key features of my preferred programming language [with which Jerry is also familiar] FORTH encourages top down design with bottom up coding/testing "clf" was a reference to comp.slang.forth newsgroup And since you are reading this ;} In a previous thread you said that you had used spectrograms of call of artic loon to demonstrate harmonics. I suspect I've demonstrated AM sidebands with my version of 3D spectrograms. Have you seen the same with traditional format. [If you wish private discussion on this my email is valid]
Reply by ●September 15, 20082008-09-15
Vladimir Vassilevsky wrote:> > > Rune Allnor wrote: > >> Probably obvious to the pros out there, but test-driven programming >> has really made a difference! >> >> I've been hacking away on some C++ code for a week now, and >> for the first time I have made a serious effort to write and run >> tests as an intergated part of the job. > > > Unfortunately, even if all parts are working, that does not mean that > the whole thing is working.*BAH* If parts don't work, in *WHAT* sense does whole work?????????? [ *SNIP* rest of irrelevant comments]> > VLV >
Reply by ●September 15, 20082008-09-15
On Sep 16, 6:33�am, Scott Seidman <namdiestt...@mindspring.com> wrote:> Rune Allnor <all...@tele.ntnu.no> wrote in news:3e4a5aef-3e3e-4a2b-8b1e- > 22efb12bc...@f36g2000hsa.googlegroups.com: > > > - One knows when one is finished, since the code apasses all > > � the tests. �Which means one avoids stress as one knows > > � the exact state of the project.I think that is overstating the value of a very valuable practice. It implies the status of the units determines the status of the whole. In a lot of projects that is far from the case.> This suggests that one knows what all the tests are before one starts > programming. �Definitely the way to go, but not always the way things are > done.It implies you know *some* of the things which must be tested at the beginning, and you really should know that much. As you realise the limitations in your test coverage, you can gradually fill in the gaps. This practice tends to work very well, if taken seriously. The last point is important, as many people are forced to do unit testing, but pay lip service to it. One of the great things a lot of people ignore about unit test suites is they provide a very efficient way to do regression testing later on. Regards, Steve
Reply by ●September 15, 20082008-09-15
On Sep 16, 5:46�am, Rune Allnor <all...@tele.ntnu.no> wrote:> Probably obvious to the pros out there, but test-driven programming > has really made a difference! > > I've been hacking away on some C++ code for a week now, and > for the first time I have made a serious effort to write and run > tests as an intergated part of the job. > > Some of the benefits: > > - One can't just write some code and expect it to be testable. > � One needs to break the code up in testable modules, which > � makes for a better overall design.I find writing for compatibility with a test harness makes me develop cleaner more reusable code. Probably because it makes me think about the functionality of the module in a more generic way. So, this practice may have psychological as well as direct test benefits.> - One can't get away by postponing all those awkward limit > � cases; they come back and haunt you in no time. One has > � to deal with them up front. Which means the implementation > � is better.In many cases it is damned hard to exercise the corner cases outside a test harness.> - One knows when one is finished, since the code apasses all > � the tests. �Which means one avoids stress as one knows > � the exact state of the project.This is far from true. Unit tests tell you about correctness of the functionality of the modules, not the system. The bits may not all fit together properly to form a system, or there could be funky real time related issues that unit tests completely ignore.> - As one tests blocks which depends on earlier blocks, one > � discovers bugs one made earlier (and thus, flaws in previous > � tests.) I just found and corrected a bug I wrote five days ago, > � due to a dependent module which failed a test.Yep. Keep fleshing out those unit tests, as you find their limitations. :-)> The Unit Test frameworks + post-build event configurations > in the VS2005 IDE has really made the job a lot easier. > Or at least more comfortable."Comfortable" and "VS2005 IDE" do *not* belong together. Regards, Steve
