eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers [Electronic resources] نسخه متنی

Testing Third-Party Libraries

Many developers are now using third-party libraries. The .NET Framework development environment encourages this by promoting the development of component-based solutions across the enterprise. When using third-party libraries, there are approaches that can be taken to maximize the quality of the code produced and reduce the cost of change through the lifetime of the system. In the following exercises, we explore how these approaches fit with the XP practices.

We All Do It

One of the classic mistakes that development teams often make is to assume that when they get a third-party library it will just work. I am not sure why this belief exists; maybe they believe the marketing hype, or the sales pitch was really good.

The flip side to this is that some developers refuse to touch third-party libraries. These developers are convinced they will definitely not work, in part, because they don't trust any code they didn't write themselves.

Our eXtreme .NET team faces this issue.

Deepak: Hey, I found this cool library that loads and saves time zones for us in an XML file. I reckon we should use it for the application. We're going to need to do this anyway. Sue: No way. That is easy to write; we can just write our own. Then we don't have to use other people's buggy code. Eddie: Hey, we can have a look at it. If we write tests for the functionality we want, then we can see if the library does what we need. Deepak: Okay, that makes sense. Sue: I am not convinced. Can I pair with someone to write the tests? Eddie: Sure, let's do it

These misconceptions can be overcome by writing tests around the library, or at least the functionality you need to use. Because you are reading this book, I bet you are thinking of using some third-party development library. How can I be so certain?

The .NET Framework Is a Third-Party Library!

For most of you, the .NET Framework is a third-party library. If you are smart, you will also be highly likely you are using libraries, components, or code developed by other teams. This code might have been developed either in your company or other companies. Why waste your time developing code that someone else has already invested their time and effort into?

Component-Based Software Development Is Here

Microsoft has been working hard on the .NET Framework, and it provides solutions to many of the failings of their previous component-based offering, COM. For many developers, COM was good enough for their component-based applications, but there were issues with scalability to very large systems and cross-platform interoperability. The .NET Framework goes a long way toward solving these problems and opens the doors wider for component-based solutions, leveraging remoting, Web services, and cross-language library integration.

If It Goes Wrong, We're All in the Brown Stuff

The trouble with the increase in utilization of components written by other teams of developers is that we are exposing ourselves to ever-greater unknowns. This is often why developers don't trust anything unless they write it themselves. This lack of trust is not only arrogant, but also commercially unviable. If we are going to use more code that we don't have "control" over, we need to find some way to protect ourselves against issues with that code. We are going to investigate how we can use some of the test-driven development practices to protect ourselves from issues arising through using functionality provided by third-party components.

Put the Alarms in Place

By writing tests for each unit of functionality that you use from a third party, you are doing three things:

You are validating your theories as to how the library works.

You are building confidence in the use of that library.

You are protecting yourself from changes in future versions of the library.

This final one is important. If you have a test suite for a third-party library that tests all the functionality you use from that library, when a new version of the library becomes available, you can run the test suite against that new version. The tests will show you whether the changes will have a detrimental effect on the software