Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 12/19/2012 03:22 PM, Bill Mills-Curran wrote: > On Wed, Dec 19, 2012 at 03:05:37PM -0500, Doug wrote: >> Date: Wed, 19 Dec 2012 15:05:37 -0500 >> From: Doug <sweetser at alum.mit.edu> >> To: discuss at blu.org >> Subject: Re: [Discuss] OT Rant/Discussion C vs C++ >> Precedence: list >> >> I am becoming a fan of Test Driven Development using Python. The hope >> is for code that is a little more readable than alternatives. All the >> tests do two things. First, it drives smaller methods because they >> are easier to test. Second it shows explicitly how to use the code. >> >> The process of writing tests and code has made me a code re-writer >> more than just a writer. My first drafts of code are BAD, although >> parts work. The tension between the test and the class file help make >> things simpler and more consistent. >> >> Another advantage in maintaining the code is that any new changes made >> after the original writer has left can be tested. There are so many >> hidden dependencies, it is hard to tell if a new fix breaks something >> else. > Unit testing has /always/ been the salvation of code developers. > Going back a ways to my ME development days... > > The company I worked for sold a large, nonlinear finite element > package. They had a large library of test cases. I developed a > regression test facility that was required to be run as part of a > developer's update. Each update would be assigned a small portion of > the test cases, and the code would be run twice: once without the new > changes and once with the changes. If there were differences, the > developer would have to sign off on them in order for his update to > proceed through the system. > > This wasn't the classical unit test (just running a few functions), > but it did concentrate on just a few features. It saved developers a > lot of embarassment, and it shortened our release QA cycle. > > Test early & often. > > > Totally agree. Many years ago I joined a company where they released 2 releases in a row that did not boot. My group is in a similar situation. The software we have is written by a European company whose lack of testing is glaring. Since the product is our product, we spend many hours testing and providing feeback to that software house. In contrast, many of our products written by our R&D people in Toronto goes through extensive regression testing. The bottom line is if you have a good testing methodology, the code maintenance will actually be a lot less expensive and you will have happier customers. -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix PGP key id:3BC1EB90 PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |