Unit Testing-Porting my CSLA.NET 5 App to CSLA.NET 6

[theafricaninternetgroup]

I am trying to port my CSLA.NET 5 to CSLA.NET 6 I am lost how to setup the test environment for Unit Tests. I tried to inject the IDataPortal into the constructor of my Unit test class but my tests failing with following message
"The following constructor parameters did not have matching fixture data: IDataPortal`1 _portal". I perused into source code of CSLA.NET
found a project called TestHelpers .Any guidance or pointers to resources on how I can use the classes in this project to setup my unit tests environment?

[TheCakeMonster]

Sadly I don't think any unit testing projects support DI. Needing to configure a DI container for unit tests is generally considered an antipattern - and yet, at the moment, it is an important part of using testing with CSLA in 6.x.

I have suggested that we offer more specific support for unit testing in another discussion - #2704 - but that is not anything that we should consider to be on the delivery roadmap at the moment. If you think that it's important then by all means add a comment to that discussion; everyone's input helps - sometimes things in open source project get prioritised based on popularity, and a comment helps show popularity.

You are looking in more or less the right place for help. I'd suggest looking at the way I set up for unit testing in the Csla.test project that forms part of the source code in the CSLA repo. This includes the majority of my latest think on, and implementation of, support for unit testing for CSLA.

I think the vast majority of test classes in Csla.test includes use of the TestDIContext class, created using the TestDIContextFactory class. As a example of just one usage, see https://github.com/MarimerLLC/csla/blob/main/Source/Csla.test/BasicModern/BasicModernTests.cs - but there are many more. You can use a shared, class-level instance across multiple tests or create a specific instance for a specific test if that is helpful; I use both depending on whether the test I am doing needs custom or default configuration.

Discussion 2704 was about making Csla.TestHelpers into a NuGet package that could be consumed directly, and at the moment I don't know when we would do that. However, all is not lost. The source code of Csla.TestHelpers is open source under the MIT license. That ensures that you are able to clone it or copy it. The only restriction comes from the copyright - you fulfil the obligations of that as long as you include the copyright notice and refer to the license at the top of each significant portion you copy. Copying code into your own project is not quite as easy as using a NuGet package - but it's not far off.

All of the examples of unit tests you could want are in Csla.test. A few of the tests still fail, but that's more likely to be due to small, low level bugs in 6.x of the Csla framework - 6.x required a huge rework over the 5.x codebase - than the unit testing approach I am using.

[rockfordlhotka]

The minimum to set up DI is basically this:

var services = new ServiceCollection();
services.AddCsla();
var provider = services.CreateServiceProvider(); // this is from memory - method name may be different
var applicationContext = provider.GetRequiredService<ApplicationContext>();
// use provider to get other services you require
// your test goes here

[ryanaw83]

Should the service provider be cached somehow? We are getting exceptions with the message 'Cannot access a disposed object.
Object name: 'IServiceProvider'.' when calling ApplicationContext.GetRequiredService

[TheCakeMonster]

Hmm, interesting. I can see the same exception being raised by some of the unit tests in the Csla solution itself. I wonder if this has arisen since the change to dispose the scope CSLA uses in LocalProxy.

Demonstrated in (at least) FailUpdateContext of Csla.Test.AppContext.AppContextTests

[TheCakeMonster]

Csla.Test.DataPortal.DisposeScopeTest also seems to indicate that we might be disposing of something that shouldn't be disposed - although I wonder if that could be a bug in the test itself in this case.