CODEWITHSUNDEEP
.nettestingbuildnuget
Will Comeaux
Will Comeaux

Reputation: 365

Better approach to testing code in NuGet packages

We have a set of projects that we are packaging. These projects/packages have a dependency graph amongst themselves. In basic terms we have Common, Client and Server (reality is a bit more complex involving 5 projects in total). I do have unit test projects for these.

Common is used by Client and Server. Client is used by Server. I call these "IFX". All of them are used in various projects/services. The services in question are targeting ServiceFabric - not exactly relevant except to say that adds an additional barrier to testing/debugging when things go wonky, thus an even longer feedback loop.

My typical process is to make a change to the IFX libraries, run a series of builds, packaging, etc. It's run Common build/package, update Client project, commit, build/package, then do Server, etc. The Server IFX references packages for Common and Client (not just project references) so a change to Common results in a new build for Client, then for Server, and then, finally for any service that needs the new version.

My main issue is with testing these. To speed dev/test (and to have a better hope that things work before going through all the packaging ceremony), I would LOVE to have more real-time feedback. I have considered creating separate projects that do project (not package) references and building one test service that references projects (not packages) just for the sake of early feedback, before I commit to the REPO and start building things that may not work. But, that gets hairy due to namespace collisions, etc. Especially, considering that the IFX themselves have package, not project references.

At this point, what I'd really like to know is, who else has run into this issue and what did you do to ease the pain? I'm aware of issues with packaging core libraries before they are stable - agreed, but the situation here can't really be changed, so, I have packages to contend with.

I've looked at ways to replace dlls in the packages folder when I am testing something, but that gets really problematic when I forget what dlls I have overwritten, so I would like something a bit more static and automatic, not manually moving dlls around.

I'll stop there before I drone on and on and just ask - any tips to ease this pain? :)

Upvotes: 0

Views: 403

Answers (1)

rbennett485
rbennett485

Reputation: 2163

Following on from @CamiloTerevinto's comment, you can:

  • Use project references between your related libraries, not package references (applications and unrelated libraries can still package reference them)
  • Make your code changes, build and test
  • Once your tests pass, run a dotnet pack on your solution containing all the related libs (project references are automatically converted to package references at this point) and publish your new package versions

To avoid situations where you end up producing a different package with the same version you probably want to use something like https://github.com/dotnet/Nerdbank.GitVersioning to get deterministic versions for all your packages.

Upvotes: 1

Related Questions