|NuGet Client Test Plan||Jeff Handley||5/7/14 3:26 PM|
As part of preparing the NuGet 2.8.2 release, we have taken our internally-documented client test plans and distilled them down into one easy-to-digest overview document. We published this test plan to http://docs.nuget.org earlier today and it can be found under the “Contribute” section at http://docs.nuget.org/docs/contribute/nuget-client-test-plan.
Testing Ecosystem Tools
There have been some expectations on us that we will test ecosystem tools, but we simply cannot do that. We fully recognize that ecosystem partners (quite a large list) who build software based on NuGet also need to take much of the same test matrix into account, but they are then also burdened with testing new versions of NuGet. On the surface, it can seem reasonable for the NuGet team to take on responsibility of testing ecosystem products’ integration with NuGet to ensure they aren’t adversely affected. However, for an ISV that is building (and sometimes selling) software based on NuGet, that software vendor owns the responsibility for testing their product with new versions of NuGet. That means staying connected to NuGet’s changes and consuming its CI builds (more info).
When NuGet does break the integration with other tools, we fully encourage those tools’ vendors to file issues against NuGet. Sometimes a change in behavior will be intentional, and sometimes not. For intentional changes in behavior, tool vendors are expected to update their products appropriately. For bugs, clearly filed issues that document expected vs. actual results will help us more quickly determine root cause, fix the issue, and create new regression tests in the area. Additionally, we would welcome pull requests that add more unit tests or functional tests to guard against unintentional changes.
Suggesting Additions to the Test Plan
Despite our inability to take on the testing burden for ecosystem tools, we do invite suggestions of additions to the test plan. If your tooling makes assumptions about NuGet’s behavior that cannot be expressed in a unit test or functional test pull request, please feel free to send a pull request for the test plan to validate your assumption. But those additions must be expressed in terms of consuming NuGet directly, and not through your tooling.
Alternatively, if you would like to include a link out to a test plan you’ve documented for how you validate a new version of NuGet, we would welcome those additions to the document as well.
Submitting Documentation Pull Requests
It’s very simple to submit pull requests for our documentation on http://docs.nuget.org. On every documentation page, there’s a footer link to the page source on GitHub.com. From there, you can simply edit the document in your browser and submit a pull request. You can of course manually fork/clone the repository too and send pull requests the traditional way—but editing the browser is usually perfect for our markdown files.
The source for the NuGet Client Test Plan document is here: