Embedded Systems Conference
Hynes Convention Center
Boston, MA
Oct. 27-30, 2008

Microsoft PDC
Los Angeles Convention Center
Los Angeles, CA
Oct. 27-30, 2008

Agile Development Practices
Shingle Creek Resort
Orlando, FL
Nov. 12-13, 2008

Embedded World 2009
Munich, Germany
March 3-5, 2009

Product News

Perforce 2008.1 and P4GT 2008.1 GA now available
Check out the latest features or download now.

P4Perl, P4Ruby, and P4Python 2008.1 GA now available.
See the Related Software page for download instructions.

Resources

Newsletter Archives

Using SCM to Focus Testing

The challenge for testing, especially in a dynamic, iterative development environment, is to know what to test. In the early stages of a project, regular meetings of the designers, the developers, and the testing staff will make it clear where the focus should be. But as development proceeds, and as the project gets closer to being functionally complete, it becomes more difficult to know exactly what the developers have been working on. And if you're facing a big, collaborative project, with hundreds of thousands of lines of code and dozens of programmers all working on it at once, it will become increasingly difficult to know what needs to be tested. SCM can help.

Tracking Change in Real Time

As testing professionals, we know that a high percentage of the defects in a system are going to be in the parts of the code that have changed the most. This is exactly the kind of information an SCM system is designed to track.

If you're a Ruby afficionado and a prolific Perforce scripter, as I am, you no doubt have a potpourri of P4Ruby scripts you've written over the years. With the advent of P4Ruby 2007.3, you now have a little problem: legacy scripts that don't work with the Perforce-supported versions of P4Ruby.

This little problem is most annoying in an eclectic and diverse development environment where a variety of workstations, laptops, and test machines are owned and operated by a variety of software engineers, and the Ruby scripts you've written are available to all of them.

For example, what if you're trying to deploy a new script, using the new P4Ruby, on a machine where an old P4Ruby is installed? Even if you did have privileges on that machine, updating its P4Ruby installation could well render someone else's vintage P4Ruby scripts inoperable! Or what if a handful of your oldest P4Ruby scripts are now falling all over themselves on a machine where someone has just installed the new P4Ruby?

The differences between the Perforce-supported P4Ruby and the previously available Perforce Public Depot versions are not huge, and it's not really that hard to convert an old script. Everything you need to know is spelled out in the P4Ruby Release Notes. But do you have the time or inclination to rewrite a 500-line chestnut that has been working just fine all these years, thank you, even if you are its original author?