My project depends on some 3rd party code. Maybe the 3rd party code is from and internal supplier, maybe it is from an external party. Either way I need to protect my investment from changes in that code.
When I choose to use a 3rd party Real Time Operating System (RTOS) I have certain needs. I want to create threads, mutual exclusion objects, and protected queues for example. Maybe I only want to use a subset of the current capabilities. (If you are not an embedded systems programmer, change RTOS to database, and the same ideas are still valid). How does the API for the RTOS work. What order are the calls? What parameters get me what I want?
When first integrating a new 3rd party piece of code we read the manual and start calling the API functions from out application and hope we figured out the nuances of the API. This has lead to hours of head scratching and bug chasing for me. We’re trying to solve two problems at once: can we make our application behave differently? And how does this API work? It is always better to work on one thing at a time. Divide and conquer.
Rather than calling the API from our application write some tests to experiment with the API. These tests show you how the API works. Once we know how it works and we know how to get what we want from it, the rest is just engineering. Then we can start integrating it with our application.
What should we do with those tests once we’ve figured out the API? Toss those tests, right? No we don’t toss them. We keep those tests as a record of how our application uses the API. The first time we try something new in the part of the API we write a test to make sure we know how it works. we might even refactor code from those tests into a thin layer of code that our applcaiton calls when it needs the 3rd party service.
The effort of adding these learning tests does not cost anything. We had to learn the API anyway, why not do it in tests. You will be more focused, and learn it faster. When we’re done we have an executable specification of how we are using the API.
Someday in the future our 3rd party vendor releases a new version. The new version is a collection of bug fixes and new features. We don’t care about the new features (yet) but we want the bug fixes. We have a risk to deal with, the risk of unintended consequences. How do I protect myself from these inevitable changes?
We have something to help us with the risk, our tests. We build and run the tests independent of the application, checking to see if the API still behaves the same. If it does, our integration risk is lower and the task can be estimated. If the tests report problems, we can better estimate the impact of the change on the application. We could choose to delay integration or continue. Either way its better to have the information and make an informed decision that to be in the dark and use the hope and pray methodology.
!commentForm
When I choose to use a 3rd party Real Time Operating System (RTOS) I have certain needs. I want to create threads, mutual exclusion objects, and protected queues for example. Maybe I only want to use a subset of the current capabilities. (If you are not an embedded systems programmer, change RTOS to database, and the same ideas are still valid). How does the API for the RTOS work. What order are the calls? What parameters get me what I want?
When first integrating a new 3rd party piece of code we read the manual and start calling the API functions from out application and hope we figured out the nuances of the API. This has lead to hours of head scratching and bug chasing for me. We’re trying to solve two problems at once: can we make our application behave differently? And how does this API work? It is always better to work on one thing at a time. Divide and conquer.
Rather than calling the API from our application write some tests to experiment with the API. These tests show you how the API works. Once we know how it works and we know how to get what we want from it, the rest is just engineering. Then we can start integrating it with our application.
What should we do with those tests once we’ve figured out the API? Toss those tests, right? No we don’t toss them. We keep those tests as a record of how our application uses the API. The first time we try something new in the part of the API we write a test to make sure we know how it works. we might even refactor code from those tests into a thin layer of code that our applcaiton calls when it needs the 3rd party service.
The effort of adding these learning tests does not cost anything. We had to learn the API anyway, why not do it in tests. You will be more focused, and learn it faster. When we’re done we have an executable specification of how we are using the API.
Someday in the future our 3rd party vendor releases a new version. The new version is a collection of bug fixes and new features. We don’t care about the new features (yet) but we want the bug fixes. We have a risk to deal with, the risk of unintended consequences. How do I protect myself from these inevitable changes?
We have something to help us with the risk, our tests. We build and run the tests independent of the application, checking to see if the API still behaves the same. If it does, our integration risk is lower and the task can be estimated. If the tests report problems, we can better estimate the impact of the change on the application. We could choose to delay integration or continue. Either way its better to have the information and make an informed decision that to be in the dark and use the hope and pray methodology.
!commentForm
Add Child Page to AlternativeToTheHopeAndPrayMethod