future proofing your code against changes in third party libraries [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

How do we future proof our code against changes in third party libraries? Maintaining unit tests seems like one way of going about it.

Answer 1

1) Configuration management. Knowing exactly what versions of your libraries go into making up your build is essential. Some distributions are very sloppy in identifying versions, so you may want to invest in a good version extractor, such as http://www.jboss.org/tattletale -- also, comparing reports over time so that you can identify what has changed in your libraries.

2) Unit tests and integration tests. The phrase "unit test" is badly misused in the community. You need to test a spectrum of behavior in your configurations.

3) Managing interaction effects. One of the toughest issues to manage is upgrading just one item. Often, point releases of libraries depend on other point releases of other libraries. You can't just take one.

4) Planning for systematic upgrading. Build into your project schedules work to do testing of newer releases so you can estimate the impacts of doing an upgrade. With that information, you can plan your upgrades for a time when you are not under the gun because it has gotten too old, or is incompatible with the next supported JVM.