Trial by cxxTest

| 3 Comments

A unit test evaluates some functionality of a small part ("unit") of a larger software project. Conceptually, unit tests aid make debugging easier precisely because they apply only to a small part of the program being debugged, so when a unit test fails, the developer need only search in the "unit" of code to which the test applies.
cxxTest is a testing framework for c++. It provides a handy interface to the code being tested, which allows the tests to be separate from the actual software. Tests are organized into "test suites" that typically apply to the code in a single file. For example, readInput_test.h could be a test suite for the procedures in readInput.cpp. cxxTest works by generating a cpp file from a .h test suite that can then be built and executed. The tests themselves are member functions to a test suite class that include calls to functions of the ASSERT family, the simplest of which, ASSERT, simply takes a boolean expression and succeeds or fails depending on whether the expression evaluates to 1 or 0 (true or false).
When a cxxTest suite executes, all the ASSERTS are evalutated, and the result is printed out in a nice format.
In our project, a language translator, we applied unit testing to the first three components in the pipe, namely the input reader, the scanner and the parser. Each of these components has its own test suite with several representative inputs and tests for important conditions as well as correct output.
We were initially (and lots of others have been) confused by the way cxxTest works, by generating a cpp file, which is then compiled normally. CxxTest doesn't work simply by including the code to test; that approach would be limited. Once you get past this concept, though, cxxTest is quite easy to use, and in conjunction with Make mitigates the pain of testing considerably.

Subverted

| 3 Comments

Subversion is a widely-used source control system. It was developed in 2000 as an open-source alternative to CVS and is currently a top-level Apache project.
Since most version-control systems have the same core functionality, I'll talk about the features of source control in general, then about subversion specifically.
The basic function of version control is to automatically archive every revision of a project as it is committed to the system. Nothing is ever truly deleted once it has been versioned and committed. Though files can be removed from the project in later revisions, they can always be resurrected from previous revisions.
Basic versioning is very helpful simply as an "undo" feature. Developers can make changes without fear that they will break the code and be unable to recover it. In addition, developers, managers or customers can view the project revision log to see what progress is being made.
The second major feature of source control is the ability to merge changes to the same file. Subversion does this automatically if the changes are on different lines. This allows multiple developers to work on different parts of the same file. Conflicts that cannot be merged automatically are raised when a revision is committed, and the commit is blocked until the conflict is resolved manually. If conflicts are likely to occur, a developer can request to lock a file until he has finished working on it.
Change-merging features enhance collaboration because, since developers can work at once on the same file, any developer can pick up code and change it without having to wait for another developer to finish and commit his changes. Both developers can test their working copies of the source, then merge them and have good reason to hope the merged file has no new bugs.
Branching is the third often-mentioned aspect of version control. In subversion, this is not really a separate feature, but a technique or convention, since there are no special mechanisms. Basically, a branch is a copy of some or all of the project source into a new location within the repository that can be modified and tested in isolation. It can then be moved back into the main "trunk" branch via the normal commit operation, which will merge and flag conflicts as usual.

When/how not to use source control


  • When you do use version control, be selective about which files you add to the system. Files that are modified automatically (e.g. object and database files) should not be versioned.
  • Source control is not a replacement for team communication: make sure everyone knows what they're working on and stays out of code that will conflict later.
  • Resolving conflicts manually is annoying. Try very hard to make sure it happens as infrequently as possible.
  • One still has to be careful with uncommitted changes. There is no undo button for changes made to the working copy. Especially be careful to only use "revert" when you're certain you want to throw away all the changes made since the last revision. It's a good idea to make a local unversioned copy before a revert.
  • Because it uses only a few simple paradigms, subversion is very powerful. It is easy, though, to make a mistake when there are only conventions and hardly any hard rules about what you can do. For example, make sure when tagging and branching that the directory structure is what you expect, since it is easy to be confused between copying a directory and its contents.

Two's company

| 2 Comments

If more than one programmer has worked on the same project, clearly there are two possible scenarios. Either multiple programmers worked on the program in close communication and at the same time, so that their changes were interleaved, or there was an assembly line in which each programmer had the code all to himself and dealt with his part independent of the other programmers.
The latter scenario may not qualify as "team programming," but it's pretty much what happened with iteration 1 with my team. The other guy did about half the work, then I took over and finished up.
Obviously this took longer than if we had been working at the same time, but time was not really a constraint, and I think this arrangement was more efficient in terms of time spent working on the assignment than if we had tried to work concurrently. The main reason is that I didn't have to worry about explaining my modifications to my partner. I was free to refactor and rewrite whatever code I needed to.
In our case, this method met our needs well, since we needed to split the work, but I suppose in the real world it would be even better in this situation to simply have a single programmer complete the entire project. There could be exceptions when there are programmers with differing skills. Perhaps a specialist writes the brains of the application, and then his apprentices wrap it in a GUI and take care of OS portability. In that case I can see not wanting to be bothered with the trimmings while the core development is going on but still wanting to give the later iterations some leeway in changing the core code to interface better with the outside world.
So I guess what I'm saying is that I didn't notice any significant advantages working in a team over working as an individual except, of course, that I personally did not have to spend as long on the project.
However, I did think that working on the project side-by-side during lab 4 was a very productive way to proceed. I think this is called "Pair programming" and I do see how it can be more efficient than working independently. It's much harder to make stupid errors and typos, and it keeps you from wandering deeper and deeper into the implementation until you're lost instead of working layer-by-layer and completing each code unit before moving on. Obviously, development time (time taken to complete the project) is reduced at the cost of increasing developer effort (man-hours spent).
So, what do we do for iteration 2? Will we want to divide the project assembly-line style again? Maybe we'll want to do the whole thing together. At this point there doesn't seem to be a reason to pretend this is a "realistic" project and try to mash together our changes in subversion. Working together or separately, but not both, seems to be the easiest way to go.

What do I know?

| 4 Comments

So, this course (according to the syllabus) is supposed to teach me some stuff. Presumably, lots of the topics on the syllabus under "Intended Learning Outcomes" will be covered. Probably I already know most of it. Let's see which days I should skip class.

I see we're going to learn "Program design and development techniques." I probably shouldn't skip these days. I do feel pretty comfortable with programming style and comment-writing, since I've worked on software projects in teams of two before. Style and commenting weren't as important as they will be in teams of six or more, but (as a rookie programmer) I got some good feedback on how not to comment and style. And, of course, I learned good style by example.

Both jobs were pretty devoid of any design philosophy, though. I guess they came closest to Extreme Programming but were pretty much "Build and Fix" projects. It seemed to work well, since needs kept changing, and the team was small. Learning to use an iterative or waterfall approach in this course will probably be useful.

I also see we're going to learn C++. I will have to learn this language sooner or later, but I find I learn languages much quicker on my own than in a lecture. Just give me a project and Google and it'll get done. So, I won't feel too bad skipping these. The Object-Oriented concept that people have so much trouble with I encountered and mastered before I graduated High School. <object type="Arrogant-sniff" />

The software models will be interesting, though. I enjoyed 4011 but thought it rather esoteric, so It'll be cool to apply those machine models to real software. I think I'll try and skip the days that cover only 4011 material, though. I already learned that.

It looks like I may have a few class periods off. I could use the commute time to, oh...say... write blog entries that are due at 9:30am.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

-- Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.

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

Recent Comments

  • macdo184: This was a really good, concise description of the technical read more
  • walim002: @henc0017, I was slightly confused by the construction of a read more
  • borkx026: Haha, I was totally confused too during that one lab. read more
  • reis0140: I forgot to leave my name. Jason Reiss read more
  • reis0140: I agree conflicts can be a pain. There are tools read more
  • borkx026: I wish we could utilize branching more on the project read more
  • ahlqu038: I agree, there is a trade-off between the assembly line read more
  • vukel025: Doing the “assembly-line” style of programming that you two used read more
  • Yujng Sun: Seems you are good at programming and very confident of read more
  • henc0017: On my previous projects, the design was already in place read more

Categories

Pages

Powered by Movable Type 4.31-en