Cxx Testing

            Programmers use unit testing to verify how well a specific section of their code works.  It is used to check that the new sections written do not affect the functionality of the previously written sections.  Basically, unit testing is done to see if the code does what the developer thinks it should do.  In the “Pragmatic Unit Testing in Java” chapter we read from The Pragmatic Programmers book, the authors describe unit testing as “essential.”  It is an inexpensive way to gain confidence in the program and makes the development process run more smoothly.

With a short story, the chapter compares a case in which a developer, Dale, uses unit testing with a case in which another developer, Pat, does not.  Pat cranks out method after method, stopping every so often to see that it all still compiles.  He works quickly, but when the deadline approaches, the code is completely nonfunctional.  He spends hours working with the debugger.  When one bug is fixed, many more present themselves and Pat misses the project deadline.  Dale, on the other hand, works more slowly, writing a section then writing a test to go along with it.  He checks that it does what it’s supposed to do before he moves on to the next step.  He rarely needs to use the debugger and when glitches happen, they’re easy to fix.  He has a working copy ready to present when the deadline rolls around.  Unfortunately, I read this article right before the iteration 1 due date for our project and realized my partner and I had been employing Pat’s faulty technique.  We realized our mistake a bit too late, but the CxxTesting lab assignment that followed, taught us some valuable skills for unit testing to use on the rest of the iterations.

CxxTest is a specific framework for unit testing.  The programmer writes the header file containing the assertions to be verified.  The header file creates the class that will implement the tests, which saves the programmer time.  The tests are run, checking each assertion, and a success rate is returned to the tester.  If any tests failed, it indicates which ones, generally with an error message saying what was expected and what was found.  This lets the developer know where to focus their attention to fix the bug.  To help find errors quicker, it is helpful to give the tests descriptive names, too.  Some common assertion macros used for writing tests include:

TS_ASSERT

                        TS_ASSERT_EQUALS

                        TS_ASSERT_DIFFERS

                        TS_ASSERT_LESS_THAN

                        TS_ASSERT_THROWS

            There are many more assertions available for the tester to use in a variety of situations.  The main advantage to CxxTesting is that the framework is very portable.  Everything needed to run the tests is included in the header files written and its own library.  No external libraries are needed which makes CxxTests easy to implement.

            Programmers tend to not be very fond of unit testing because it can be tedious and seems to stand in the way of actually coding more of their program right away.  It can feel time consuming and difficult.  But how much effort should one put into unit testing?  The answer is that developers should put in as much effort as they need to convince themselves that the code (previously and newly written) is working as well as expected in order to move ahead with the next section in the project.  With more detailed testing, bugs are easier to find and fix, and programmers gain more confidence in their code when the tests are completed successfully.  Putting more effort into unit testing translates into more valuable feedback for the developers.  Dale’s “slow and steady” approach, which places the importance of quality before speed, although monotonous at times, is the most beneficial approach when developing software and helps prevent the headaches that come along with debugging.

Subversion

Source control, also commonly known as revision control or version control, is a tool used for managing changes to files of a long-term project.  Source control is especially useful when there are many people who need to make modifications to the same project.  It can provide organization in multi-developer scenarios because everything is stored in a central location. All the developers have access to this central location and it’s where they keep the master copies of the files they’re producing.  Source control is able to support multiple releases of the same project by using tags, meaning snapshots of each iteration of the project.  Using this tool also supplies a project-wide undo button, making it easy to get rid of mistakes and revert to an older, correct, version of the development.

Subversion is one specific open source version control system, which we have been using while building a translator for the class project.  The central storage location in subversion is referred to as the repository.  Each group member has what is called a workspace on his or her own computer.  The developer can view the differences between their own version and the repository version then update their workspace to the latest copy from the repository.  They make changes on the local copy and commit the new version back to the repository for everyone else to see.  If more than one person happens to be working on the same file at the same time, subversion will show the conflicts between the copies when the second person attempts to commit the file.  Conflicting edits must be resolved before it can be committed successfully.  Subversion provides a way for all the team members to keep track of older versions and specific releases of the project.

Subversion is a great tool when working with people from a distance, or working with people with conflicting schedules.  In my experience from working on the class project, its sometimes hard to get two college students’ schedules to match up when trying to set aside work time.  With subversion, my partner and I can work on our own time and communicate our progress through the comments we leave with each committed version of the code.  We don’t have to be at the same computer to see the latest changes, nor do we have to email back and forth constantly.  Its easy to see how version control would be a great tool for businesses whose programmers work with programmers across the country or even overseas.  If development heads down the wrong path, this would normally be a disaster, but subversion gives the ability to revert to an older, correct, version if necessary.  A log is kept of all the committed revisions.  Another advantage of using subversion is being able to work ahead toward the final goal, yet saving each release of the software.  Tags can be used as markers for important steps in the project.  We have been using tags for submitting each iteration of our project for grading.  This way, we don’t have to wait for our project to be graded before we modify our code for the next iteration.

When using version control it’s important to remember not to commit buggy code to the repository.  It would be unproductive for teammates to update to a buggy version.  Leaving descriptive comments is another important thing to remember when using subversion.  Good comments are helpful if a team has to decide which revision to revert to, or if a teammate just wants to get a general idea of what was accomplished on previous commits.  Recently, we came across an issue when making a tag for the second iteration of the project.  The directory of our tag was off a level from the main project branch, which made the path to the cxx tests in our makefile off by a level as well.  It was simple enough to fix so that the tag would function properly, but it was an extra detail to worry about and remember to fix on the main branch after copying to the tag.  We haven’t really had any other issues with subversion thus far.  I found the commands for controlling the repository very straightforward to learn.  After looking them up once or twice, the commands become simple.  They are intuitive and do exactly what they sound like they would do.  Copy makes a copy of part of the repository, log shows the history of commits, and diff shows the differences between copies.  Subversion is an easy tool to learn to use and has great effects on the overall organization and productivity of the software development process.

Working in Groups

People often dread being assigned group projects for their classes, but for programming, I actually find it beneficial to work in teams.  One of the most valuable tools we use in this class is subversion.  It would make no sense to simply be told that such a tool exists and then never actually learn how it works until you show up to your first group task at your first professional job.  We wouldn’t develop any practical skills with subversion, beyond submitting a tagged version, if we were to work individually on this project.  I found it helpful to be able to work on the same document at the same time as my partner, compare our progress, and merge our work together.  It is easier to work through problems when producing code with someone because you can talk through your ideas out loud and reach an appropriate solution sooner.  When my partner and I were stuck trying to figure out what we needed one of our functions to accomplish, it sparked a conversation.  This quickly led us to implement some new variables and a loop to solve our issue.  It’s always handy to have someone double check your thought process and build off of it.  Another convenient thing about working with others is that each person can contribute different knowledge.  As an example, I felt I had more experience with makefiles and header files from a previous course, whereas my partner had more experience with C++ programming in general.  Group work is a good way to pick up on tips and tricks from your peers.

The most apparent advantage of group work is getting to divide up tasks so there is less work for each individual involved.  We were each able to accomplish things while the other was unavailable.  On one occasion, I was unable to attend office hours because of a conflicting class schedule, but my partner was able to go and get our project questions answered.  I found our work time to be more focused and disciplined than it would be if I were to work by myself.  Having to follow up with a group member regularly means I’m less likely to take breaks or get distracted.  It’s pretty painless to maintain a nice flow when working with others, as well.  If a problem is encountered, one teammate can fix the interrupt, and the other can continue to move forward.  For us, the flow did not get slowed down much by the tedious tasks. In our while-loop that checked for a token match, replicating all the if-statements for each regular expression was somewhat monotonous, but did not become a time setback since we were each able to work on different things at the same time.  Through group work on iteration 1 of this project, I was able to learn some new programming tools and techniques and gain experience with time management for team project deadlines.  I’ve realized there are a lot of advantages to working with others, especially when developing a program.  It’s a lot less stressful than taking on the whole project independently.

Course Topics

There’s always a lot of uncertainty on the first day of class, but there’s one thing students can count on: a syllabus. This could, in fact, add to the uncertainty and overwhelm some students, but hopefully seeing an overview of the course can instill some excitement for the semester to come.  For Csci 3081w this semester, our syllabus includes a long list of topics we can expect to cover.  I was pleasantly surprised to see areas on this list in which I already have some background knowledge.  The first one that caught my eye was writing effective comments.  I feel I’m comfortable in this area because ever since the first program we were assigned to write freshman year, the professors and TAs continue to remind us that the clarity of our code is important to our grades.  Whenever I’m writing comments, I think about what someone would need to know if they were reading through my code for the first time.  I’ve learned to use comments to explain why things are grouped or organized the way they are.  Comments also benefit me, as the program developer, because they can serve as “landmarks” if the code is particularly lengthy.  I also feel I have reasonable knowledge in the area of writing loops and code in general that is easy to understand.  This topic goes hand in hand with writing useful comments. Seeing loops and keywords implemented in multiple languages such as Scheme, Java, Python, C, and Assembly has taught me when and where to use these tools.  Creating long programs for class projects has also taught me that having variables with appropriately descriptive names goes a long way toward producing readable code.  I am comfortable using a debugger, too. Last semester, I did a project, called bomb lab, where we had to use GDB to step through disassembled binary code to help us find what the program was expecting for input so that I could ‘defuse the bomb.’  This didn’t really teach me how to use a debugger for software development purposes, but it was a good way to become familiar with basic debugger commands which could be useful in the future for finding errors in a program.

The first area from the syllabus topic list that I hope to improve upon is code reviewing.  I imagine reviewing my peers’ code is somewhat like my previous experience as my high school newspaper co-editor.  Both articles and code have to be readable by others.  Your article isn’t going to run if its full of errors, and neither will your program. I hope to learn ways to provide constructive criticism about software development this semester. A second thing I need to work on is developing good tests. Generally when I’m nearing completion of a project, I get excited about finishing it and lose focus of what test cases I need. I want to gain the skills required to be an objective test case writer to ensure my program works in all situations.  The final area that looked especially interesting to learn about this semester is using model types such as UML.  Based on a quick flip through the UML textbook for this class, this modeling language reminds me a lot of blueprints, like an architect would create for a team of builders.  It will be useful in my future career to be able to communicate a project design visually to all involved in the process. The next few months in this class will be a great balance between applying my previous knowledge and gaining new skills for developing programs.