On Unit Testing


Unit testing is a very important tool that can and should be used when working on software projects. Unit tests can help you define interfaces by writing the tests for those interfaces first. If you write the tests first you have a clearer purpose for the module you are coding. This often allows you to find design flaws before you implement them saving more time than it took to write the tests.

Once you have written a new interface and have passed the tests you can now use the test as a regression test to run every time new code is checked in or modified to ensure your class is still working properly. The more tests you have the more execution paths you can cover with your tests and the more confidence you can have that your code stills functions as before.

A test should be short and test one single case. The more details you cover with your tests the easier it will be to pinpoint bugs in your code. The tests also become documentation as they detail how each function is supposed to work. So when another programmer wants to use your module they can look at your tests for code examples of its functionality.

A test suite is a collection of tests that will be run in succession. One test suite should cover the functionality of an object. Test suites are a way to organize you tests, each suite should stay with the code it tests to be used when it is integrated into other projects.

When you want to test the result of method call you can write an assert statement to compare the result to the expected value. If the result is not as expected the test has failed and a message will be displayed. If the test passes no message will be printed. No news is good news I guess.

A setup functions can be defined in your test suite to be called before each test is run to create a new object so you start your test with know object state. You can also create a setup function for the test suite that will be run only once in the test suite. You can setup global resources in this function, such as database connections.

A teardown is the similar to a setup function except it is called after your test is run to clean up the resources created for the test. Likewise a teardown function can be created for the test suite to handle global clean up.

Write the tests first, let them all fail and then complete your code making each test succeed. This gives you a feeling of progress that can sometimes be lost in big projects. Also the tests provide with a to do list of functionality. Once all your tests pass you know you are done with that class, at least until you find a bug. Then you can write a new test to expose the bug and squash it.

Unit testing offers many benefits which often outweigh the cost in time of writing them. Once it becomes part of your development style you should have more confidence to tackle new problems. This confidence is also a feels really good that you write code that works and you have something to show for it. Everyone should try to make unit testing part of their routine.

On Subversion


There are many flavors of version control to available to programmers. Subversion is one of them and quite popular due to its ease of use and flexibility. I have used subversion for a couple of months and have found it handles core version control functionality in a very straight forward manner. There are a small number of commands to learn to get started.

Using subversion, sharing with my partner was a breeze. Armed with a URL, user name and password, one simple 'svn checkout ' command was all I needed to get started. Then I could add files to the repository or modify and upload any existing files. My partner could also download and modify the files I had added, or add his own. This allowed us to split the project work between us easily. As long as we would commit our changes and update changes from the server frequently, we were essentially working in the same file system.

Working with a partner there were times when we modified the same file. Subversion automatically merged the changes, as long as they were located in different parts of the file. If the same part of the file had been modified, it would mark those lines in the file. That made it easy to see the changes we each made and decide which code to keep.

Subversion also keeps a history of everything you commit. So if you ever need to get back to a point where things may have worked a little better you have that option. You can also create a copy of a source directory to have a snapshot of a software release, also know as a tag. This comes in handy once you have a program working but want to refactor your code to be more readable and modularized. You do not have to worry about losing that functionality since the code is with the repository and you can always revert.

Here is a quick primer on the basic commands of subversion. If a repository has been created on a server, all you need is the URL, user name and password. Then use the 'svn checkout ' command to create a local copy. You will be prompted for the user name and password. The a copy of the repository files will be downloaded from the server into your local file system.

After you have a copy on your local machine you can use 'svn add ' to add files and 'svn commit ' to upload any changes to the server. When you want to see what files you have modified or created but not added, you can use 'svn status' to list them. You may also see in the status that files have been modified remotely by another user. You can then issue the 'svn update' command to download and merge those changes with your local copy. If you wish to ditch your current changes to a file, the 'svn revert ' command will re-sync your local copy with the server.

Overall subversion is a simple a powerful version control tool. Using subversion can save you many work hours with its history backup. It also eases the pain of transferring files between computers. These features are useful if you are working in a group or alone. Also there are programs available that integrate the features of subversion into your file system manager. This makes using subversion as easy as a right click.

Group Think or Group Stink?


An education in Computer Science provides many opportunities to work on small projects. Many projects could be done by a single person. So why do our instructor's insist working in groups? Won't I learn more if I do everything myself? No, you won't. Working in groups is one skill that should be at the base of every programmer's repertoire. The more you can experience it now will help you down the road.

That being said working in groups has challenges and benefits. One challenge is being able to communicate effectively. Some issues that arise might have many working pieces that are difficult to express in writing alone. Sometimes a snippet of code can be included with a description of the symptom you notice and directions to where you suspect the issue is.

Another challenge is melding their code with yours. You have to read someone else's code and they might have a different style than yourself. This can be difficult at first but here is where you can learn a thing or two by their example. On the other hand you may be able to show them an other way to do the same thing. In most projects you will utilize code from other programmers. Whether it be from a colleague or an open source project, you will need to know how to incorporate their code. This will save you loads of time since their code is most likely tested and bug free, well we hope so anyway.

A benefit of working in a group is having someone using and testing your code on another system. Another person might test different code paths or try something a slightly different way to reveal a bug. Often when coding and testing we can get a narrow view of what our code should do. A fresh perspective doesn't have this disadvantage and can bring fresh ideas.

As with most life experiences the challenge becomes the reward after you are through it. Working with others can be a bit of work at times but mostly it is enjoyable to share the struggles of development. Now is the time to make connections with your peers. You never know who you'll be working with in the future.

Program Design and Development Expectations

| No Comments

Through my experiences writing code, for software projects at school and work, I have come into contact with many topics of this class. As Professor Wyk has already mentioned in class, this class was created to address the concern of important software development practices being missed in other classes. These practices enable a programmer to look at work as a craft rather than work.

I have used a few Version Control Systems in the past such as: Source Safe, CVS and Git. I have found Git to be my favorite. I like having a local repository to commit into without merging with the remote project. Also Git will compress files before sending them across the network making it perform very well. Having a version control system in place makes it easy for multiple developers to work on the same project. It also allows you to make changes in your code without the fear of breaking everything, if I doesn't work you can just revert the changes and you are back where you started.

Writing effective comments is another important topic of this class that I have had experience with. In my summer internship I wrote documentation for two existing software projects. Some of the most important comments I found were explaining the reason the decision to write a piece of code in a certain way. Documenting roadblocks and workarounds in a comment can save time for the next person to read the file.

Modular Software Design and Unit Testing are topics I am looking forward to receiving more in-depth information about. Know the right level of abstraction to design and using inheritance effectively make coding solutions easier.

Unit testing is also very helpful. If you don't write unit tests then your production code modules are your unit tests. Test helps find bugs and let's you rewrite code without the fear and assurance that things still work as expected.

Recent Comments

  • jashn002: Great job explaining unit testing. Writing out tests beforehand can read more
  • marqu245: The last two paragraphs in particular resonate with me. I read more
  • Nicholas Ellis (ellis348): I really liked how you said let all your tests read more
  • lowxx060: I agree with your idea that one will feel more read more
  • lowxx060: I agree with your idea that one will feel more read more
  • yakow001: I agree, subversion is a great tool, especially for group read more
  • dowd0070: Subversion has a basic yet powerful feature set that makes read more
  • macdo184: Hey, I agree that programming in groups has a lot read more
  • lexxx320: I too agree that merging code has been a difficult read more
  • tieng001: I agree that with working in groups, merging different the read more

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