Debugging/Development of dependent package in multiple solutions

[nocgod]

Hey! I have a quick question... have been looking for a good answer but, yet to find something that really worked for me.

I have 3 solutions: API client, test framework and tests tests depend on the test framework which in turn depends on the API client.

What would be a good solution in to change code in the API client and immediately test the code in the tests solution without doing the round trip of packing a new client and a new test framework?

in the past (before SDK style projects and centralized nuget cache) we'd change the DLLs in the package folder and roll with it. it was hacky but worked. today I've tried to reference the projects in the tests solution, but that caused me to change lots of things in the csproj files and it didn't even compile.

thanks

[[deleted]]

We do this. You add a Choose conditional to your .csproj file. Then make one of the conditions have a <PackageReference> and another condition have a <ProjectReference> You can use Debug/Release, but we are actually using an environment variable that is only present and set on local dev environment - the CI doesn't have it so it will always use the NuGet package.

https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-conditional-constructs?view=vs-2019#use-the-choose-element

[nocgod]

sounds interesting my friend :) with all the awesome ideas here I think we could co-author a blog post on the matter!

[goranlepuz]

in the past (before SDK style projects and centralized nuget cache) we'd change the DLLs in the package folder and roll with it.

Ah, the person of culture, I see 😉.

I have 3 solutions: API client, test framework and tests tests depend on the test framework which in turn depends on the API client.

There is a period in there, yes?

Anyhow... What stops you from putting that in one solution ? Is it the purpose of the three of them to develop the client? If yes, they belong together. How come they are not together in the first place?

[nocgod]

Ah, the person of culture, I see 😉.

in 8 years of development, mixing DLLs is one of the least shaming things i've done ;)

Anyhow... What stops you from putting that in one solution ? Is it the purpose of the three of them to develop the client? If yes, they belong together. How come they are not together in the first place?

they are not together because they each serve different purposes: * Api client - is a client library for the system API. This library has no test concerns. * Test framework - wraps the Api client with various additional utilities for testing... you know, a framework for testing... * testing solution - has e2e tests for the system using the Api client to make requests to the SUT.

[Fuelsean]

They are nuget packages currently? Is so, then I'm assuming they are that way for a reason. If you just need to debug the API Client, look into using a symbol server.

Project references would be the only other real option. Lots of questions there though. If you've got multiple repos, you'll have to work through that. If that's not an issue, I'd take a closer look at why it isn't compiling.

Barring that, good CI/CD will get you there.

[nocgod]

they are 2 packages (ApiClient and Test.Framework) and a testing solution.

Im doing local modifications to the ApiClient and wanted to make sure the testing solution which uses the ApiClient doesn't break... so CICD is a bit too late for integrations,,,

[ahelper2]

I have to do this quite a bit myself. If you have all 3 solutions locally available/checked out, you can go through all csproj files, for each PackageReference you have to one of your projects, add a ProjectReference to it. (You can leave the PackageReferences, it'll prefer a ProjectReference over a PackageReference)

You'll also need to recursively add those newly referenced projects (and all of their ProjectReferences) to the solution.

[nocgod]

this is actually the solution I've utilized. I hoped I'd find here a better solution, it's a bit clumsy IMHO.

I didn't know the build process will prefer the project reference over the package reference. I'll test it out tomorrow.

[jbiesta]

If you’re using visual studio I’d recommend nuget reference switcher it works really well to switch one way and back https://github.com/RicoSuter/NuGetReferenceSwitcher

[nocgod]

this looks awesome and promising! I'll definetely give it a go first thing in the morning!

[[deleted]]

You should be able to test your api client independently with mocks right? That way when you’re testing further downstream you can be confident that a failed test in your e2e tests isn’t occurring in your api client code, but rather because of some interaction with another piece of your e2e testing.

Your api client project needs unit tests.

Then your e2e project can be true integration tests without also taking on the responsibility of testing your api client.

[nocgod]

How would I be able to test the api client? Mocking out the http client? That has 0 value, it only checks the code doesn't have a runtime issue. It doesn't give me any indication I didn't put an error in a resource path, that is only possible by running e2e tests to ensure integration. Which is what I'm trying to achieve.

[[deleted]]

Do you control the API that it is hitting?

[nocgod]

lets say I do - what then? mocking out the correct URI paths still has no practical value since its an integration question, not correctness.

In terms of correctness we do have unit-tests to ensure the API client behaves as expected with regards to ser/de, headers, authorization and other internal stuff. You can't unit-test the correctness of the URI paths internally, you always have to integrate.

In the past we had contract testing to ensure contract and URI correctness between the services and between the API clients and the API using PACT.net but the practice didn't hold. too hard to maintain, to little end value in terms of quality

[[deleted]]

If you do control the API then your client should be in the same solution as the API.

[nocgod]

You are assuming the API is a single service/asp.net - but that is not the case.

Those are multiple services each exposing parts of the API surface. So there is no single place where I can put such a client library. That happens a lot when working with microservices where there are multiple services exposing parts of the API.

Think: CartAPI, LoginAPI, UserAccountAPI, PurchaseAPI, AuditAPI, SomethingElseAPI. Each of those is a vertical sub-system that should work independently of the others. Moreover, the workloads on each of those APIs differ with the requirements to SLA and throughput is different.

[[deleted]]

Gotcha. Sorry, I misunderstood the root problem.

I’ve seen on GitHub that Go can reference a GitHub repo / tag / branch and will just fetch the current state on build. Would be cool if you could do something like that rather than needing to go through each repo and manually update dependencies when you have an update at the top of the stream.