Testing

| No Comments

I was trained as a scientist and I've always thought that programs were similar to experiments. Like experiments, programs test theories of how things are supposed to work, and like experiments, programs have (sometimes unpredictable) results that can be analyzed. In very simple experimental terms, we can ask "does this program do what I intended it to do?"

One way to figure this out is to add code to your program that tells you what it is doing. Since writing my first programs, I would add code like this to my code to tell me what is was doing:

cout << "The value of x_coord inside the polar_converter function is: " << x_coord << end;

My code would be littered with sometimes dozens of text output statements like this, each designed to show me that some specific piece of code was doing what I thought it was doing. Some outputted the value of a variable. Sometimes they would just mention that a portion of code was executed without any error occurring. "File Loaded..." But each line of code like this was meant to function as a small window that showed what was going on in a program at a given step. But as all of these windows piled up text on the command line, I would have to add empty text lines or long strings of "-----" just to group the output into "paragraphs" that could be more easily read.

When the program was complete, I would then go about commenting out all the extra cout (or print) statements. Manually. To me it was like pulling off the tape that covered the wooden trim in a room you just painted. The end product was clean and sharp and smelled good too.

And then my mind was blown... In a class lecture, Eric Van Wyk went over some code examples and introduced the notion of a DEBUG flag. What a great idea! The DEBUG flag is a global variable that is set to 1 or 0 (TRUE or FALSE) and acts as a switch to turn off and on all of the little output statements you put into your code to see what it does. Therefore, a programmer doesn't have to go back and comment out (or uncomment back in) code that serves a debugging function.

Brilliant! What a timesaver! I wonder who invented that. If there's one thing I take away from this class, and it's this idea, then I consider this whole class was worth taking.

The DEBUG flag is a global variable that turns statements or code sections on and off globally. But sometimes we want to test portions of code individually. We call these portions of code "units" and apply the term "unit testing" to testing these portions. Usually a unit is an individual function, but it can also be defined as a functional unit containing multiple functions or programs. While testing one variable may consist of writing a simple output statement (as above), testing a function (or unit) can be a more complex task. But like variable testing, it involves inputting a know value and evaluating the output.

In class we were introduced to a C++ unit testing framework called CxxTest. Getting started with CxxTest was a little confusing. After downloading and setting up the CxxTest library, we compiled and ran an example provided by our class instructors. After getting it to run, I took a closer look at the code and saw how functions in my program were being called systematically from a "test.h" header file which had a corresponding "test.cpp" file. At first glance, this seemed really complicated and it looked like a lot of extra work to write the that "test.cpp" file. Wasn't this framework suppose to reduce tedious and repetitive work? As soon as I realized that the CxxTest suite wrote that .cpp file on its own, I really started to see the benefits it could provide. CxxTest organizes tests into "Test Suites" that are written into the header files and then then the "test runner" C++ files are generated automatically.

I'm starting to see a pattern in the way I deal with new software and new programming tools. Both with CxxTest and with Subversion, I seriously underestimated what the programs were doing. In the case of Subversion, I thought I had to re-check out and re-check in files each time I booted up my computer. But I didn't need to because Subversion keeps track of that (magically). With CxxTest, it took some time for it to actually register that this system was automatically writing code for me.

Working in Groups

| No Comments

Programming with a partner or in a group is not fun for me. Not because the people that I've had to work with in the past were un-fun or unhygienic. Mostly they've been sincere, smart, hard working and odor free. I think the situation is difficult for me because I don't have a lot of experience working with a partner. Though I've taken several programming classes with group projects, group work is still the exception and not the norm. I'm used to working independently, on my own programs, dealing mostly with myself. Though I'm very comfortable working on my own, I'm sure that I'll get more comfortable working in a group as I get more experience with it.

Maybe working with a partner is hard because writing (relatively) small programs is not a particularly Parallelizable task. (That's right, I said Parallelizable.) Some tasks can be more easily accomplished by adding more workers, just like the performance of some programs can be enhanced by adding more processors to a system. Many metaphors are commonly pulled out to illustrate parrallelizability. For example, making rolls for dinner or painting a room would be more quickly accomplished with more people working on them. Other activities, like cooking a chicken take the same amount of time no matter how many chefs you have working on the project.

I think that writing a (relatively) small program is a difficult task to parallelize. The hardest part of the Project Iteration 1 was building the scanner. I didn't realize how much work writing it would be, so I told my partner that I would write the scanner. Even after starting to realize how much work this writing would be, it was hard to break up the scanner function into tasks my partner and I could do at the same time. Maybe future iterations will be easier to break up because they will have more functions. And maybe the process will get easier as our parallelizationating skills get sharpened.

One big issue associated with breaking a project into smaller pieces for multiple people to work on is the idea of equality. Ideally, we want each person in a group to be given their fair share of responsibilities. We think it's not fair for one person to do more work than another. But, because it is often hard to predict how much time it will take to write a working piece of code, it can be hard to equally distribute a programming workload. It is difficult for me to propose a solution to this other than to wait for more great advice in class on how to better deal with the some of the more unpredictable aspects of writing programs.

Hello, World of Program Design!

| 7 Comments

I think that success in any discipline, particularly in engineering and computer science, is the result of a complex interaction between discipline, learning, personal aptitudes, experience and knowledge. And while being a mathematical genius can certainly help you write amazing programs, the ability to see a bigger picture or to work precisely and efficiently probably helps create more great programs than mathematical genius alone. In other words, how a program is put together can influence whether a program succeeds or fails just as much as the tiny technical details in each line of code.

These kind of "bigger picture" ideas like "best practices" for programming, writing modular code, reviewing code and considering program design in general have rarely been mentioned in the (half a dozen or so) computer science classes that I've taken at the U of M. So after reading the course description, the "Program design and Development" course (CSci 3081) sounded really interesting to me. I don't know much about these things and would love to learn more. And right now I have the luxury of taking only classes that sound interesting to me. That's because I work full-time (I have a B.S. in Biochemistry) and I haven't really been following the official major sequence for the Computer Science major.

I've had coursework covering C and C++, and I have written some significant code (both in class and for my job) and feel like I can get real things accomplished with these languages. But I'm definitely not a code guru and I'm probably a slower coder than most of the programmers I know. I have experience using C++ with OpenGL and I have a working familiarity with XCode for the Mac and the .Net framework on the PC. The ideas of testing frameworks, documentation generators and automation tools sound really interesting to me too, but I don't have much of any experience with them.

Generally speaking, I hope to learn more about all these "bigger picture" ideas that can help make me a better programmer.

Recent Comments

  • frank915: There is what seems to be a big fuzzy cloud read more
  • ande9286: As you mentioned, being able to envision the bigger picture read more
  • ande9286: As you mentioned, being able to envision the bigger picture read more
  • yorks006: I haven't seen much emphasis in the design of programs read more
  • torge135: I too can see what you mean about the importance read more
  • khanx107: I don't mean it this in a bad way, but read more
  • borkx026: I agree with you on the notion of seeing the read more

Find recent content on the main index or look in the archives to find all content.