Category Archives: Software Development

Developer Testing

Testing is a hard problem because there is no way to guarantee that a certain product or piece of code is 100% bug free. Many organizations have testing or “quality assurance” departments who are responsible for doing the majority of product testing before software goes to the customer. Even with a dedicated testing department, developers still have a role to play in testing their code. This article describes the developer testing philosophies used on the project I work on. The project is a server application that mainly manipulates and creates documents.

After the developer testing is complete, the build should be in a good state to enter testing by the quality assurance group. The beauty of this is that it all can happen automatically overnight.

Nightly Builds
A full build of the project is automatically run each night after the developers go home. This is not a testing method by itself but it provides a process for further testing. Developers know that they cannot check in code into version control that will not build that evening. After a new feature has been committed, all members of the team can have access to this the next morning and ensure it works properly. If required, this build can be given to others outside the development team. This is a fully working version of the product that may even go to the customer.

A report of the build is emailed to the team indicating if the build passed or failed. Each build has a unique build number that is the same as the Subversion revision number. This way the build number is unique and the developers can get that exact build code from the source code repository if needed.

Nightly Unit Testing
After the nightly build is done all of the unit tests are run for the whole project. We try to restrict the unit tests to test true “units”. That is to say, test a single class or a very small number of classes. All of the unit tests are either Java JUnit tests or Groovy unit tests. A report of the unit tests is generated using the junitreport ant task. This indicates which tests passed and failed with information on any errors.

Nightly Integration Testing
After the unit tests are complete a set of integration tests are run. These integration tests test the entire product. The integration test suite installs the product, runs the product and then performs a series of tests to ensure that the basic end-to-end functionality of the product works. On this product a bunch of test input files are processed through this running server. The outputs of these are validated to ensure everything works properly. A lightweight test harness was created in Java and Groovy to do run the integration tests and perform this validation. This framework was created from scratch rather than basing it on JUnit as these tests are specific to the application domain. A report for these tests is generated.

Performance Testing
Performance is an important part of this application. The same test harness that runs the integration tests can be used to run the performance tests. Instead of validating if the software works, the speed in which the software performs its tasks is measured. This can be compared to previous versions of the software. This is not run with every nightly build because it takes more than 24 hours to run. It is instead run on occasion over the weekend.

What makes a language Dynamic?

I read an article the other day on coding horror that discusses size is the enemy of software development. One of the opinions from the article was:

If you’re starting a new project, consider using a dynamic language like Ruby, JavaScript, or Python. You may find you can write less code that means more. A lot of incredibly smart people like Steve present a compelling case that the grass really is greener on the dynamic side. At the very least, you’ll learn how the other half lives, and maybe remove some blinders you didn’t even know you were wearing.

I agree 100% with this statement. Where the confusion often comes in is what makes a dynamic language “dynamic”. Is it because of dynamic typing? Is it strong vs weak typing? What about the presence of a MOP?

A lot of the buzz around dynamic languages has been created by the Ruby community, particularly around the Rails application. As described in the previous quote, dynamic languages provide features that allow you to write less code that means more. What about Ruby on Rails allows developers to write less code? There is more provided there than dynamic typing alone can provide.

So what is the definition of a dynamic language? Graeme Rocher had a great session at grails exchange on “Dynamic Groovy – Meta Magic” where he addresses this issue in the introduction. He defines a dynamic language as a language with a Meta Object Protocol (MOP for short). A MOP is (definition from Meta Magic):

A mechanism that makes the semantics of a program extensible.

This definition is a bit vague but in a nutshell it allows classes to be dynamically modified at runtime. Typically these languages also provide language level ways to intercept method invocation and property access.

There are many languages that support dynamic typing like Visual Basic, BeanShell, Ruby, JavaScript and Groovy but not all of these have a MOP. According to Graeme the main languages that support a MOP are Groovy, Ruby, Small Talk and LISP.

I do agree that a dynamically typed language like JavaScript allows the programmer to write “less code that means more”. The point that I’m trying to make is that a language that is dynamically typed AND has a Meta Object Protocol allows the programmer to write even less code than one that just has dynamic typing.

The meta object protocol is what allows applications like Rails and Grails to create and extend domain classes at runtime.

For this reason, I would recommend that if you are starting a new project, consider using a dynamic language like Ruby or Groovy. A dynamically typed language with a Meta Object Protocol allows you to write less code that means more than a language with no Meta Object Protocol.

Just like Taking out the Garbage (With Version Control)

I had a Mathematics teacher in High School who used to get very excited over factoring problems where you could simplify expressions by canceling out terms. He used to say it was just like “taking out the garbage”. Taking out the garbage was not usually a fun task but it is surprisingly satisfying to get rid of stuff that is not necessary and is just clutter. I run into this same sort of thing when developing software. I just love to “take out the garbage”.

Version Control software is essential to any project, no matter how small (That in itself is a topic for another day). Version Control software gives you the ability to take out the garbage all of the time without having to worry about losing something that is important. You can always go back to old versions of a file if you need them at a later point in time.

Delete Unused Classes

Often when you are refactoring a component or adding something you end up with a Class that was used before that is no longer relevant. Delete it. Remember that you can always get it back later if you need it again through your Version Control system. It does not matter how ‘useful’ this code was, how ‘nice’ it looks, how ‘cool’ it is. It may have been a useful utility that you might need again. You have to resist these urges to keep it around. Unless you know for a fact that you will use it again, you should get rid of it. It is not gone forever and you can get it back if you need it. This will help reduce the complexity of your code and consequently the readability.

Delete Unused Code, Don’t Comment It Out

I see a lot of developers who take a piece of code that is no longer used and comment out the entire section. Resist the urge to keep it inside the code. You can always get the code back through version control, so why do you want to keep a long comment block somewhere where it needs to be maintained? Another danger to this is that if you do want to use this code later on, you will likely end up removing comments around code that no longer compiles. Things change and this once working code may no longer work after you uncomment it.

The follow code is a good example of this. The line that was commented called a function that takes 2 parameters. Notice that the current version of the function takes only one. Code blocks that are commented out are not compiled so the code is not kept up to date with the rest of the code.

// We don’t need to do this anymore
// variable = someFunction(a, b)

someFunction(a) {

}

It is simply better to just delete the code block. If you need it at some point in time later, the version control software can resurrect your lost code.

Bug #12324 Add a heading here
Bug reference numbers are not necessary

I have seen lots of code with comments around a changed block indicating the change was for a particular bug. Before long, the code has a mess of comments all over the place indicating bugs that were fixed and where. This is another case where version control software can eliminate comments that unnecessarily clutter your code. This one does require a bit more discipline though.

Always indicate the bug number being fixed and a small when checking in code into Version Control. For example, you could add a comment like “Bug 12324: Added heading to section”. Then when you look through the Version Control log, you can easily see where changes were made and what they were made for.

If you are looking at a particular line of code and you need to know where it came from and why, you can use the “blame” feature. That will give you the person who last changed the line of code you are looking at along with the comment (which should include the bug number and fix description). For more information on this feature of version control systems, check out the “Who wrote this Crap?” (http://www.codinghorror.com/blog/archives/000992.html) article on Coding Horror.

Taking Out the Garbage

So next time you are confronted with “stuff” that is not longer used. Delete it and let your version control do the work of remembering it. This will keep your code much cleaner and easier to read. It is just like taking out the garbage.

From Waterfall to Agile

I read a great article today on the future of software development. It gives a great summary of what is wrong with the waterfall method of development and how agile methodologies try solve this problem.

The problem was that the Waterfall Model was arrogant. The arrogance came from the fact that we believed that we could always engineer the perfect system on the first try. The second problem with it was that in nature, dynamic systems are not engineered, they evolve. It is the evolutionary idea that lead to the development of agile methods. (article)

Management is often slow to learn of new trends in software development. The fact that agile has been around since the nineties and many institutions still have not heard of it proves this point. I believe the best way to bring agile methodologies into an existing organization that uses the waterfall or another approach is to bring them in slowly. This is what we have done in my organization and it has been very successful. Here are some good starting points for change.

  1. Change how requirements are viewed. If you are handed a set of requirements for an entire product release, plan for them to change no matter how “final” you are told they are.
  2. Split the development cycle into iterations. At the end of each iteration reprioritize your tasks for the next iteration. 3-4 weeks is a good length for an iteration. Create a full release of your product at this point whether someone will actually use it or not. Hopefully you will have a QA team to test it at this point but it is important to create a fully working version of the product anyway.
  3. Leave the design of system components to the iteration they will be developed in.

Pretty soon you will find that your Waterfall approach is a lot more agile than it used to be. I encourage you to keep changing your approach as you find what works best for your organization.