testcontainers
refactor(sln): functional grouping of projects
functional cohesion to ease navigation.
It prevents you from jumping up and down in the solution explorer by placing the tests and the sut more close together. Give it a shot and see if you like it.
Deploy Preview for testcontainers-dotnet ready!
| Name | Link |
|---|---|
| Latest commit | 7f7ccf07f36f2a48b5ef817a7b5625e0ed9e4484 |
| Latest deploy log | https://app.netlify.com/sites/testcontainers-dotnet/deploys/646b66ba58d96a0007566eb6 |
| Deploy Preview | https://deploy-preview-863--testcontainers-dotnet.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
The idea for this PR stems from the cohesion theory that functional cohesion is much better than logical cohesion. This is what I nowadays do in projects where I do hexagonal architecture/ports & adapters. I then put the adapters in separate projects and group them into solution folders with the test and integration test projects. It is my experience that there's less jumping around in the solution tree that way since when working on an adapter it makes sense that the tests covering that adapter are nearby.
This same theory also applies to some extend to your project, but I can imagine it for you being less ideal. Like you said, when changing something in the "core" you need to update all "adapters" as well. So no hard feelings when it doesn't work out for you. More then happy that you showed the willingness to give it a shot 🤟🏻
With more modules, this structure may make even more sense. I am currently thinking about minor adjustments. I will prepare a proposal.
You don't need a proposal, you're the maintainer 😎 It would be great if you could cherry-pick my commit and amend it to properly attribute it to me ❤️
Right now, I am playing around with different configurations, considering generating Visual Studio Solution files for each module automatically. This has the advantage that we do not need to load and compile all projects. However, we need to keep in mind that refactoring may require loading all projects anyway.
Right now, I am playing around with different configurations, considering generating Visual Studio Solution files for each module automatically. This has the advantage that we do not need to load and compile all projects. However, we need to keep in mind that refactoring may require loading all projects anyway.
Instead of creating solution files per module, you can also create solution filter files. With that you have still a fully maintained solution with all modules in place, and you can load a specific module also...
Right now, I am playing around with different configurations, considering generating Visual Studio Solution files for each module automatically. This has the advantage that we do not need to load and compile all projects. However, we need to keep in mind that refactoring may require loading all projects anyway.
Instead of creating solution files per module, you can also create solution filter files. With that you have still a fully maintained solution with all modules in place, and you can load a specific module also...
Good idea. Maybe we can put them in the module directory? Then devs can open only the module they are interested in.
Good idea. Maybe we can put them in the module directory? Then devs can open only the module they are interested in.
It may be a good idea to collect the set of *.slnf files in a central root folder, such as /filters. instead of scattering them all over the tree.