Possible bug? Aspect test not generating expected .t.cs file

[WhitWaldo]

Looking again at the project here I tweaked it a little bit. The whole thing builds, but I'm having trouble getting the aspect test to generate as it should.

If we turn our attention to the Innovian.Aspects.Dapr.WorkflowRegistration.AspectTests project, it has a reference to Innovian.Aspects.Dapr.WorkflowRegistration.Fabric which in turn has a reference to Innovian.Aspects.Dapr.WorkflowRegistration. Without a reference to the Aspect testing library, the Intellisense shows that the Fabric is property applying the aspect to the DaprRegistrationHelper type as follows:

And if we look at the transformed code, we get the following, as expected:

using Dapr.Workflow;

namespace Innovian.Aspects.Dapr.WorkflowRegistration.AspectTests;

public static partial class DaprRegistrationHelper
{


    public static void RegisterAllEntities(WorkflowRuntimeOptions c)
    {
        c.RegisterWorkflow<global::Innovian.Aspects.Dapr.WorkflowRegistration.AspectTests.Workflows.MyWorkflow>();
        c.RegisterActivity<global::Innovian.Aspects.Dapr.WorkflowRegistration.AspectTests.Workflows.MyActivity>();
        c.RegisterActivity<global::Innovian.Aspects.Dapr.WorkflowRegistration.AspectTests.Workflows.MyOtherActivity>();

    }
}

So that works exactly as I want it to. But I want to set up a test to validate this, so let's add the latest (2024.2.19) Metalama.Testing.AspectTesting package to the *.AspectTests project. Now, looking at DaprRegistrationHelper, it says no aspects are applied and that's to be expected.

Using the MSTest context menu option, I then Run Tests to have it generate the .t.cs files in "/obj/transformed/net8.0". I don't generally care about the other files generated, so looking just at DaprRegistrationHelper.t.cs, I see it has produced this:

namespace Innovian.Aspects.Dapr.WorkflowRegistration.AspectTests;
public static partial class DaprRegistrationHelper
{
  public static void RegisterAllEntities(global::Dapr.Workflow.WorkflowRuntimeOptions c)
  {
  }
}

It's inserting the method as expected with the argument, but it's skipping over each of the other types in the project that the fabric should have observed.

Briefly looking what it should have done:

1. The fabric identifies all types that implement an abstract base class called "Workflow"
2. The fabric identifies all types that implement an abstract base class called "WorkflowActivity"
3. Each of these collections of full type names are passed into a string array for each, respectively, on the WorkflowRegistrationFactoryAttribute aspect which is then applied to the type named DaprRegistrationHelper.
4. The aspect then builds a registration statement for each of the listed workflows and workflow activities

In summary, this aspect works as expected if I don't have the Metalama.Testing.AspectTesting package installed and it fails to work if I do have it installed (meaning that the transformed class isn't transformed as it should).

What am I doing wrong here? Thanks!

[gfraiteur]

I don't know what's wrong in the aspect, but I suggest you put a breakpoint in the template of RegisterAllEntities using meta.DebugBreak() and debug the test. You will see what is happening.

[WhitWaldo]

After more testing, I want to clarify the ask.

The aspect appears to be working precisely as expected, but when Metalama.Testing.AspectTesting is applied to the aspect testing project, the Fabric doesn't appear to fully work as expected. Yes, it applies the aspect and it runs, but it fails to discover any of the types it's supposed to (and does in a project that doesn't have Metalama.Testing.AspectTesting enabled).

Per the other thread, I see that the .i.cs file is showing up for the introduced type, but it simply reads as:

// Final Compilation.Emit failed.
namespace DaprUtilities
{
  public static class DaprRegistrationHelper
  {
    public static void RegisterAllEntities(global::Dapr.Workflow.WorkflowRuntimeOptions c)
    {
    }
  }
}

From this, I can conclude that it's properly introducing the class and it's introducing the expected method, but it's not inserting the registration statements expected to have been discovered by the Fabric.

How can I get more information regarding the error message at the top of the file: "Final Compilation.Emit failed"? Are fabrics fully testable?

[prochan2]

You may need to include the .cs files from the Workflow directory in your test. To do that, add the following to the beginning of the test. (E.g. to the DaprRegistrationHelper.cs.)

// @Include(Workflows\MyActivity.cs)
// @Include(Workflows\MyOtherActivity.cs)
// @Include(Workflows\MyWorkflow.cs)

[WhitWaldo]

@prochan2 I guess that's part of the problem though - where do I put the test for an introduced class (in this case, DaprRegistrationHelper)?

I see that the "Program.DaprRegistrationHelper.i.cs" file is created in the /transformed directory, but if I drop it into the program named either "Program.DaprRegistrationHelper.i.cs" or "Program.DaprRegistrationHelper.t.cs", it isn't noticed by the test explorer as a test that needs running. It does fully populate with each of the expected statements, but I just cannot figure out how to ensure it's included in the project tests.

[prochan2]

Even though it might be doable, I'd rather use a unit test project to test the transitive project fabric.

In the aspect test project, you should prefix all .cs files that do not represent a test with an underscore. You then include them in individual tests using the // @Include(_File.cs) comments. I'm sorry for not mentioning this before.

Another option might be including the project fabric source code file in the aspect tests, instead of referencing the project containing the fabric.

[Zu-Hy]

Hello,
This message reminds you that your request is pending and awaits your feedback.
If we do not hear back from you, we will close this ticket. We look forward to your response.

[WhitWaldo]

Adding the @include statements on the unit test itself remedied this issue. It can be closed as solved at this point.