in reply to Programming strategy with no on-going testing
Greetings Punkish,
Though I am relatively new to perl, I feel inclined to share with you what several if not all of my old college profs shared with us as students. Certainly arguments can be made for both sides but none-the-less here is what we were taught.
Many of my professors used analogies for coding. One of the more common ones was the process of building a car. Manufacturers do not just throw one together and run through the testing afterwards. Each individual component is tested for various weaknesses before the vehicle is put together. Once assembled, various systems within the vehicle are tested as a whole.
Most of them swore by the following method for larger projects. (I am making the assumption you are one of the 99% of us that do not create SRS documentation with milestones.)
Break your code up into the smallest possible functional parts and as you program test those parts. For instance, if you were inserting a a record into a DB from a text file then first check to ensure you have successfully created a session with your DB table then actually test your insertion method. In languages like Perl this requires writing stubs for all of the other necessary code snippets. So if you were inserting a line from a text file then store the test info in a scalar variable and plug away. After you have coded your app in the above manner you can stress, top-down, bottom-up, increment, blackbox, or whitebox test your entire program to look for joint weaknesses.
Sorry if any of you found this response long winded,
hok_si_la
Though I am relatively new to perl, I feel inclined to share with you what several if not all of my old college profs shared with us as students. Certainly arguments can be made for both sides but none-the-less here is what we were taught.
Many of my professors used analogies for coding. One of the more common ones was the process of building a car. Manufacturers do not just throw one together and run through the testing afterwards. Each individual component is tested for various weaknesses before the vehicle is put together. Once assembled, various systems within the vehicle are tested as a whole.
Most of them swore by the following method for larger projects. (I am making the assumption you are one of the 99% of us that do not create SRS documentation with milestones.)
Break your code up into the smallest possible functional parts and as you program test those parts. For instance, if you were inserting a a record into a DB from a text file then first check to ensure you have successfully created a session with your DB table then actually test your insertion method. In languages like Perl this requires writing stubs for all of the other necessary code snippets. So if you were inserting a line from a text file then store the test info in a scalar variable and plug away. After you have coded your app in the above manner you can stress, top-down, bottom-up, increment, blackbox, or whitebox test your entire program to look for joint weaknesses.
Sorry if any of you found this response long winded,
hok_si_la
|
|---|
In Section
Meditations