CSLA 6 integration tests

[JacoJordaan]

I am starting to convert existing CSLA 5.5 objects to CSLA 6 and are running into an issue with creating the same integration tests against a mock repository.

For CSLA 5.5 I have an AssemblyInitialize mehtod in the test project that will create the required services e.g.

var server = new TestServer(new WebHostBuilder()
                .UseEnvironment("Development")
                .UseConfiguration(new ConfigurationBuilder()
                    .AddJsonFile("appsettings.json") //the file is set to be copied to the output directory if newer
                    .Build()
                    .ConfigureCsla())
                .UseStartup<Startup>());

My objects use static methods to call the dataportal ( which is not allowed anymore).
For the tests, I will call these methods to create the objects e.g.

        [TestMethod]
        public void CustomerSearchAll_CustomerSearchList_Count()
        {
            var criteria = CustomerSearchCriteriaEdit.CreateCriteria();

            CustomerSearchList searchList = CustomerSearchList.GetCustomerSearchList(criteria);

            Assert.AreEqual(5, searchList.Count, "Expected Customer Search count = {0}", 5);
        }

What needs to change to get this working in CSLA 6?
I understand that I will probably use factory objects to inject the dataportal to create the csla objects, but I have no idea how to configure/call this in an integration test.

[rockfordlhotka]

I actually don't know: does mstest use DI to create the test objects? If so, you could inject the required services into the test class.

I imagine not though.

What you need is access to the ApplicationContext instance, which is a scoped service registered by the AddCsla method that you need to call in your AssemblyInitialize method within UseConfiguration.

My guess is that the entire test suite runs within one DI scope - as created in the AssemblyInitialize method, and so that means ApplicationContext is basically a singleton (which is good in this case).

Basically, what you need to do is implement a global static property - probably in whatever class hosts your AssemblyInitialize method. Sort of like this (using GitHub as my text editor, so forgive mistakes):

public class TestHost
{
  public void AssemblyInitialize()
  {
    var server = new TestServer(new WebHostBuilder()
                .UseEnvironment("Development")
                .UseConfiguration(new ConfigurationBuilder()
                    .AddJsonFile("appsettings.json") //the file is set to be copied to the output directory if newer
                    .Build()
                    .ConfigureCsla()
                    .AddCsla())
                .UseStartup<Startup>());
      ApplicationContext = server.Services.GetRequiredService<ApplicationContext>();
  }

  public static ApplicationContext ApplicationContext { get; private set; }
}

Then, throughout your test code, when you need an instance of a service, like DataPortal<T>:

        [TestMethod]
        public void CustomerSearchAll_CustomerSearchList_Count()
        {
            var criteria = CustomerSearchCriteriaEdit.CreateCriteria();
            var dp = TestHost.ApplicationContext.CreateInstanceDI<DataPortal<CustomerSearchList>>();
            var searchList = dp.Fetch(criteria);

            Assert.AreEqual(5, searchList.Count, "Expected Customer Search count = {0}", 5);
        }

[JacoJordaan]

Thanks, I have tried it this way, but I get a null reference exception when calling dpCriteria.Create() method.
The CustomerSearchCriteriaEdit is an editable business object.

        [TestMethod]
        public void CustomerSearchAll_CustomerSearchList_Count()
        {
            var dpCriteria = TestHost.ApplicationContext.CreateInstanceDI<DataPortal<CustomerSearchCriteriaEdit>>();
            var criteria = dpCriteria.Create();
            var dp = TestHost.ApplicationContext.CreateInstanceDI<DataPortal<CustomerSearchList>>();
            var searchList = dp.Fetch(criteria);

            Assert.AreEqual(5, searchList.Count, "Expected Customer Search count = {0}", 5);
        }

From blazor, the dataportal ApplicationContext properties looks like this (it is working correctly):

From the test project, the dataportal ApplicationContext properties looks like this:

I assume the null reference exceptions is the cause of the issue.
Am I missing any other configuration code maybe?

[JacoJordaan]

@rockfordlhotka, I have found that the httpContextAccessor.HttpContext is null on initialize of ApplicationContextManager.
Does anybody have any idea what my cause this?

The TestAppServer class:

   public class TestAppServer
    {
        public ApplicationContext AppContext { get; private set; }

        public TestAppServer()
        {
            var server = new TestServer(new WebHostBuilder()
                .UseEnvironment("Development")
                .UseConfiguration(new ConfigurationBuilder()
                    .AddJsonFile("appsettings.json") //the file is set to be copied to the output directory if newer
                    .Build()
                    .ConfigureCsla())
                .UseStartup<Startup>());
            AppContext = server.Services.GetRequiredService<Csla.ApplicationContext>();
            
        }
    }

Part of ConfigureService method in Startup class calling AddCsla:

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddTransient<QuickPartSearchCriteriaEditCreator, QuickPartSearchCriteriaEditCreator>();

            services.AddHttpContextAccessor();
            services.AddCsla();

        }

[rockfordlhotka]

The IHttpContextAccessor is made available by the call to AddHttpContextAccessor as you show. That should be available in any aspnetcore app. I imagine it is not available in an mstest environment, because that's not hosted in aspnetcore.

What host is running your code?

[TheCakeMonster]

I know this is now an old post and that the O/P probably considers it resolved, but I've only just seen it. I've been working on the tests for Csla itself, so I have some experience in this area and it felt like posting my thoughts on this subject might be useful to others who follow our path.

Unless you need it for something else, you don't need to (and I wouldn't) make use of WebHostBuilder in tests. Fortunately Rocky showed me the path in that regard when it comes to using DI in tests; you only need to create an instance of the ServiceCollection type, configure it, and then build it.

Here's a snippet from some working tests in the Csla source itself:

// Initialise DI
var services = new ServiceCollection();

// Add Csla
services.AddSingleton<Csla.Server.Dashboard.IDashboard, Csla.Server.Dashboard.Dashboard>();
services.AddCsla();
serviceProvider = services.BuildServiceProvider();

// This instance of IServiceProvider can now be used to create instances of things, for example:
var dataPortal = serviceProvider.GetRequiredService<IDataPortal<MyBusinessType>>();

This code will probably evolve as the updated configuration methods in Csla 6 are finalized, so don't take this snapshot of the code as it was the day I posted it as final. I'm putting this functionality into an assembly called Csla.TestHelpers for use in performing the tests that check the framework itself, so that's the best place to look for more up to date examples of how to do this as future you has the same problem as me here in the past!

[richardgavel]

I'm using the WebApplicationFactory as described in https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-6.0#introduction-to-integration-tests because I want a full up integration test the same way my Blazor app will be communicating with my ASP.NET Core API. But having trouble.

There are 2 containers (one inside the WebApplicationFactory and one in an independent ServiceCollection).

If I only stand up the first container, I can hit the simple Get method on the api/DataPortal endpoint.

If I only stand up the second container, I can get an instance of the IDataPortal service I need.

With both, however, I run into issues. I think I solved one of them by forcing the ApplicationContextManager as opposed to letting CSLA infer it as seen here (using the fallback generic one instead of the host specific one):

csla/Source/Csla/Configuration/ConfigurationExtensions.cs

Line 65 in f91496f

private static void RegisterContextManager(IServiceCollection services)

.

Now, the issue is that the controller isn't seeing the incoming content as a Base 64 string (I'm assuming something is wrong with the serialization).

[rockfordlhotka]

I would expect that you need to override the default context manager for unit testing. The detection and defaults are for normal app scenarios.

Regarding the data stream being a string or not, that's a setting on the HttpProxy (client and server), and you might need to explicitly set that as part of your simulated client configuration. It should be an option in the UseHttpProxy(o => o. ...) call.