No, I don't mean the cheap wine.

I'm talking about the unintended consequences of a change to an application in other areas of that app. It's not uncommon, especially when enhancing or changing features in a large, legacy application like Visual FoxPro. Fortunately, in our case, we have a crack staff of developers who are great at minimizing ripple...but it still happens.

In an object-oriented development tool, such as Visual FoxPro, ripple can become a serious matter.  As a simple example, assume that one has a parent class for all textboxes in an application. So it's decided that on entry into application textboxes (GotFocus), the ControlSource data is requeried to ensure the latest information is displayed for lookup tables managed outside of the application. Well, the change works great until data is being edited in a non-lookup form, then changes to a cursor are lost upon entry into a textbox as previous changes are overwritten by the requery.  In this case a minor change has engendered major ripple - the solution may involve a whole new subclass of the textbox with the behavior specifically for lookup tables. Then individual textboxes have to be replaced by the new subclass as required....lotsa work.

Most of the time, ripple effects are a lot more subtle. Problem A was solved but it reactivated older Problem B. Problem B may be wholly unrelated to Problem A, but they both shared a common object or routine that was changes and Problem B was slammed.

Ripple cannot always be easily foreseen.  Assume in an accouting application that a new feature opens the chart-of-accounts for potential changes, so the table is opened shared and only locked when committing changes. All well and good, but suppose there is a non-modal process within the application that requires an exclusive lock on the chart-of-accounts?  Kersplat if the customer runs both at once.

The solution to catch ripple?  If a change or addition uses common files or common routines of other areas of the application, you should run your entire test suite versus the application when the new stuff is checked in. Yes, of course, you should unit test the change on it's own, but re-running your entire test suite will guarantee minimal ripple effects.

That is, if you have a solid, broad test suite.  But that's a whole 'nother topic....