<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Cyntax1: I am currently in a small team that is trying to find the best way to test a set of development libraries.(we are testing an SDK).
I find this to be far different from just testing an application.<HR></BLOCKQUOTE>
Well, to a certain extent you are testing an application - your SDK. In that sense, you will test the functions that your SDK makes available and the structures that your SDK allows you to create. For example, if your SDK provides an API, you just do standard API testing.
If your SDK comes with sample code that allows people to see how the SDK is used, you need to make sure that code works as described.
If your SDK allows plug-in functionality then you need to test that plug-in ability.
As an example, if you were testing a Web-based SDK (like the WebSDK, the DOM SDK, or the CUseeMe Web SDK) then you might create Web pages that expose all the available commands in those particular SDK's. To take your analogical example of DirectX, with this I would test not only the DirectX API function set that is made available via the SDK but I would also test its ability to "plug-in" to the various development languages, such as Visual C++, Visual Basic, etc.
For the libraries that you mention, it depends on what the libraries do. For example, if they control text and graphics displays, or if they provide real-time processing logic, you are going to want to test those particular things.
Your SDK is just another type of application: it is a "kit" that provides development tools to another application. So a lot of your testing will not really be that different, per se, than strict application testing that you are probably used to. Your focus of how that testing is done may, of course, be a little different.