Testing for Regressions During Software Upgrades
Always plan for software upgrades in advance when you implement your modular application. When you upgrade software, the main considerations are:
Changes to the user-visible aspects of the application are not only inconvenient by they can cause an application to behave unpredictably or prevent upgrading altogether. In particular, design your API carefully because your application must support it indefinitely.
Preservation of existing data implies that:
The key to successful upgrading is to design robust data structures that will change very little as the application evolves. If you change your fundamental data structures, upgrading becomes a serious issue. Therefore, spend time thinking about the best representation of the data, independent of the short-term needs for displaying or manipulating it, because these often change in the longer run.
Caution: If you use a built-in G2 class, particularly arrays, lists, variables and parameters, as part of your public data structures, you cannot alter or extend the class when you upgrade. As a general rule, you should subclass built-in G2 classes to allow for future extensibility if they are part of public, permanent data structures in your application.
You must never save data that constitute an application of a certain module in the module itself; this would imply the loss of data when you replace the module with another version. This is particularly important for user preferences, which developers often implement incorrectly by allowing end users to change parameters stored in the module. To avoid overwriting user preferences when you upgrade a module, create an object that represents the user preferences and store the object in a user-defined KB.
GFR provides support for correct handling of module settings. See the G2 Foundation Resources User's Guide for details.
Copyright © 1997 Gensym Corporation, Inc.