Coder to Developer: Tools and Strategies for Delivering Your Software

 < Day Day Up > 


If you’re employed by a large organization, you may have the luxury of working with a well-staffed and trained quality assurance (QA) department who will test your code. If you’re in a small shop, you might well do most of your own testing. Either way, you should have some feel for the major types of testing that most software is subjected to, and you should appreciate that part of your job as a developer is to perform your own testing.

Types of Testing

Every developer knows that software requires testing, but that simple word “testing” encompasses quite a few activities. Here are half a dozen types of testing that you might consider for any given application:

Testing for Developers

As a developer, you might engage in any or all of the forms of testing I’ve discussed. But unit testing and integration testing are typically the most important of these activities for developers. One typical pattern of work for developers in a team looks like this:

  1. Check out the module that you’ll be working on.

  2. Write the code for the next feature you’re implementing.

  3. Write the unit tests to test the feature.

  4. Make sure the code passes the unit tests.

  5. Get the latest code for the entire application from your source code control system.

  6. Make sure the whole project passes the integration tests.

  7. Check in your code and unit tests.

RULE

When there are multiple developers on a project, it’s important to run the integration tests before you check in your changes.

Running the integration tests before checking in the code is the easiest way to make sure that your code doesn’t inadvertently break some other part of the application or interact poorly with another change that was checked in while you were working on your own changes.

Warning

Although developers sometimes do their own system testing, it’s definitely a better practice to have someone else do this. It is very, very difficult to give code a thorough systems test when you’re the one who wrote the code. If you had a blind spot about a potential problem when you were writing the code, you probably won’t think to test that problem later on.


 < Day Day Up > 

Категории