Testing a NuGet package

Question

We are big users of NuGet, we've got 25-30 packages which we make available on a network share.

We'd like to be able to test new packages before they're built and released in the consuming applications. Ideally, this could be done using something similar to Maven's snapshot and having a specific development package (e.g. snapshot functionality).

Has anyone else come up with a, ideally reasonably non-hacky, way of doing it?

Our favoured method is to generate the package assemblies and then manually overwrite the assemblies in the packages/ directory, i.e. to replace the actual project references, but that doesn't seem particularly clean.

Update:

We use a CI build server which creates builds on every commit and has a specific manually triggered NuGet build which works off specifically tagged versions of the codebase. We don't want to create a NuGet build off every commit, but we would like to be able to test a likely candidate in the wild before we trigger the manual NuGet package build.

Answer 1

I ended up writing a unit / integration testing framework to solve a simular problem. Basically, I needed to verity the content of the package, the versions and info, what would happen when I installed and uninstalled the package, what versions were the assemblies in the lib, what bits the assemblies were built as (x86 or x64) and so on - and I needed it all to run without Visual Studio installed and on my build machine (headless) as a quality gate.

Standing on the shoulders of giants like: Pester, PETools, and SharpDevelop's package management module I put together - nuget-test

1. Clone the project into your package directory (where your .nuspec file and package files are). If for whatever reason you want to keep the nuget-test project as a "git" repo then simple remove "remove-item nuget-test/.git -Recurse -Force" from the command below.

   git clone https://github.com/nickfloyd/nuget-test.git; remove-item nuget-test/.git -Recurse -Force

2. Run Setup.ps1 in the root of the nuget-test directory in an x86 instance of PowerShell.

   PS> .\setup.ps1

3. Write tests and place them in the nuget-test/test directory using the Pester syntax.

4. Run the tests.

   PS> Invoke-Pester

Project page: nuget-test
On github: https://github.com/nickfloyd/nuget-test

I hope this helps you get closer to what you're trying to get done.

Answer 2

If you're using NuGet packages to distribute your libraries, you should not limit to only testing the libraries. You should test the packages themselves as well (if your binaries are OK but incorrectly installed, consumers still have issues). The whole point is to improve this experience.

One way could be to have an additional CI or QA repository. The one you currently have is actually your "production" repository containing consumable releases, considered finished high-quality products.

Going further, you could have a logical package promotion flow (based on Continuous Integration or even using a Continuous Delivery approach), where: - each check-in produces a package on your CI repository - testers pick up a CI package for QA and if found OK promote it to either a QA feed, or to the Production feed (whatever you prefer, depends on the quality of your testing and how well it is automated)

There are various ways of implementing this scenario, using simple network shares, internal NuGet.Server or Gallery implementations, or simply use http://myget.org to give it a try with minimal cost and zero effort.

Hope that helps!

Cheers, Xavier