How do you test code that uses third-party libraries?

In over 12 years building Android apps, I have adopted some strategies to test such codebase. Some of the strategies I have used include: 1. Mocking - Mocking allows you to mimic objects and or API responses. Admittedly, this is not the best though. 2. Integration Testing - Another approach I have used is integration testing. Also called, Integration and Testing (I&T). Its a way of testing separate software entities as a combined unit. How does that apply here. In the Android context, this involves evoking the libraries and integrating their responses or functionalities. 3. Just Test : In my opinion, this is straight forward. Just test them like any other part of your code. Design your test cases, execute with the library and see results.

Testing code that relies on third-party libraries is an important aspect of software development, as it helps ensure that your application functions correctly, even when dependent libraries are updated or changed. The following steps can be followed; 1. Unit Testing 2. Mocking 3. Dependency Injection 4. Integration Testing 5. Test on Different Library Versions 6. Test Error Handling 7. Test Edge Cases 8. Use Test Doubles 9. Continuous Integration (CI) 10. Regression Testing 11. Documentation 12. Monitoring and Alerting

- Select libraries that are standard so that they work in the production environment. - Select very specific libraries to avoid downloading extra code. - Select libraries developed by reliable and safe entities. - Perform extensive testing in the QA environment.

Testing code that utilizes third-party libraries involves isolating the code under test from external dependencies, using techniques such as mocking and stubbing to simulate library behavior and employing dependency injection to enable testing with alternative implementations. Conducting both unit and integration tests ensures your code functions correctly in isolation and when interacting with external libraries. Managing library versions, ensuring robust error handling, and performing tests in a controlled environment is vital for maintaining reliability and stability in your application. Neglecting to test code using third-party libraries can lead to undetected issues like unexpected behaviors and system failures.

Generally, third party libraries used in any project doesn’t contribute to challenges if the reputation, documentation and community support for the library is well placed. However, in cases when per call charges are involved I have always found using a stub matching the response of the original library to be the solution for unit testing or exhaustive testing. We can always revert and connect to the original libraries when conducting a SIT or a regression test.

What I prefer is - Don't mix external dependencies directly in your code, use wrapper classes and functions and separate them from your main logic, in future it will help you if you want to change them. - For testing write?a?mock for those functions and then you can test them easily. For NodeJS I prefer mocha &?chai or Jest.

One of the most effective ways that I've used to test codes that have dependancies is by isolating the dependanciws from the code. Creating a wrapper for the external library and thus isolating it from the code not only makes it easy to mock the dependancies and test the code functionality but also makes it easier and low effort to change the dependancy library where you just have to modify the wrapper code and rest everything stays intact.

One aspect to consider is which dependency management you use for building and bundling your product/deliverable (jar/war/ear). For example maven due to the way it is designed will pick up the first dependency it finds during conflict of version, resulting in old version to be picked up. Due to which you could be facing strange behaviours due to transitive dependencies.

Mocking frameworks, such as Moq, NSubstitute, FakeItEasty, and JustMock for .Net tests. Moq and Nsubstitute are the most popular with Moq being used the most.

Integration tests are really helpful to make sure the functionality (End to End Check) is behaving as expected. - In NodeJS there are multiple option but I prefer mocha, supertest or jest for this.

Build wrapper interfaces and classes to that allow you to use them in your program. This also makes building integration and unit tests easier with the API's as you can test specific calls in your functions and intermix the calls in your own classes to build out the data or render things you need from the API itself.

Whilst you could use JUnit for integration tests, I wouldn't state it explicitly, it could give the wrong impression that it's only used for integration tests and nothing else (could confuse beginners)

There are multiple ways to test external software, it can be unit testing in case if you are able to break stack to small enough executional units, can be testing through tools like Postman, Curl if it’s a web app and has complex dependencies and writing a unit test becomes too heavy, can be mocking as already stated by others, but I personally don’t like mocking because you can not get the real output, my preferred method is integration testing, in my opinion the best way to test 3rd party libraries because you test it as whole framework with full functionality and real output with integration testing, besides a lot of cases 3rd party services are provided over the web with their own servers and integration becomes the only way then.

Exception handling is really important because this is the way you can control the unpredictable situations/errors in your project. - Add proper exception handling - Use proper logging and email triggering in case of exceptions - If some third-party library suddenly fails or changes it will help you to protect your code from crashes and you can quickly update

Sometimes this can be very hard to achieve if you have projects with large amounts of dependencies in them, so you should use tooling to monitor your dependencies to help highlight any critical vulnerabilities that surface. Tools like Dependabot from GitHub can help achieve this. These types of issues are particularly important in preventing supply chain attacks.

It's also worth making sure you understand how your dependencies are being included - are you "pinning" a specific version or using SemVer ranges which would allow the build system to include a newer version automatically. Using SemVer ranges avoids the need to make a PR for every little minor version update to every dependency, but it also could lead to a breaking change or bug coming in without you knowing about it.

Whilst this is generally good advice, it doesn't really relate to third party libraries in the way that the rest of the article does. Also calling Eclipse and PyCharm "refactoring tools" just sounds... wrong?

Test for accessibility. The standards set by the Web Content Accessibility Guidelines (WCAG), Americans with Disabilities Act (ADA), and other legislation and guidelines are helpful when evaluating the plethora of tools available. Choose a tool that fits your application and libraries. Incorporating your third party libraries in automated or scheduled accessibility testing will help to cover gaps in accessibility that may occur over time. Contact the maintainers of those third party libraries to address these gaps. Additionally, providing a way for end-users to contact your developers about any gaps in accessibility will ensure that you do not entirely rely on the tool(s) you have chosen to test.