Refactor library into sub libraries

[egil]

To make it easier to maintain and extend the library with support for other Blazor project types and testing library types (e.g. nUnit), I want to separate the library in to the following:

• bunit.core
• bunit.web (this will include JSInterop mocking, since that is web specific)
• bunit.xamarinforms or bunit.mobile (not part of the initial refactor)
• bunit.xunit
• bunit.nunit (not part of the initial refactor)
• bunit.mstest (not part of the initial refactor)
• bunit (default project, that just includes bunit.core, bunit.web. and bunit.xunit, to stay 100% compatible with current package)

Dependencies in each project should then be:

• bunit.core
  • Blazor
• bunit.web
  • bunit.core
• bunit.xamarinforms
  • bunit.core
• bunit.xunit
  • bunit.core
  • xunit.core
• bunit.nunit
  • bunit.core
  • nunit
• bunit.mstest
  • bunit.core
  • mstest2
• bunit
  • bunit.core
  • bunit.web
  • bunit.xunit

The new folder structure should be:

• docs
• sample
• src
  • bunit
  • bunit.core
  • bunit.core.tests
  • bunit.web
  • bunit.web.tests
  • bunit.xunit
  • bunit.xunit.tests
    ...
• template

TODO

• Reorder into new projects
• Tweak dependencies (xunit major version dep only)

closes #5

[StefH]

Good idea.

Maybe just deprecate bunit. Only the early adopters used this preview version. So no harm in refactoring here.

And if you build any library, make sure that the required dependencies are as low as possible. (For example I noticed that bunit.xunit required the latest version from xunit, which means in my case updating my test projects to match that xunit version)

[egil]

@StefH good point StefH. I am trying to figure out how to best manage dependencies. Ideally, my dependencies will be more limited going forward, and only depend on major versions of a library, if possible, or at the required long-term support version, in aspnetcore's case.

My idea with keeping the bunit package around is inspired by xunit. They have a similar setup, where if you just install xunit, you get a bunch of other packages that you are very likely to need. That makes it easier to get started. More advanced scenarios allow you to pick only xunit.core and xunit.assert and skip other parts.

[StefH]

@egil Sorry, maybe a stupid question from my side : why do you actually need xunit as dependency ?
And what is the reason you use Shouldy and not FluentAssertions?

[egil]

For the razor based tests and snapshot tests, I need a test runner, unless I create my own, which is quite a bit of work. If you are only writing c# based tests, then you will, when this is done, just be able to pick the bunit.web library, and use whatever test framework to run the tests you want.

There should only be a dependency on Shouldly in the test project for bunit. I use that simply because I like the vocabulary it comes with.

ps. there are no stupid questions, ask away.