It would be nice to give the testcase code displayed against the result..

[nagkumar]

As most archunit test rules can be reused across multiple products and projects.. it would be nice to display the code used against the result so that cut and paste is easy or easy to teach people against the result itself.

[hankem]

Sorry; I might not have understood entirely what you meant with "against the result", but could you clarify where exactly you suggest to display the code?

[nagkumar]

as per the view shown above..

controller_public_methods_should_return this could be a hyper link, on mouse over or click, it can say.. the code for that is

 public ArchRule controller_public_methods_should_return = methods().that()
								       .areDeclaredInClassesThat()
								       .resideInAPackage("..controllers..")
								       .and()
								       .arePublic()
								       .should()
								       .haveRawReturnType(BaseResponse.class)
								       .because("here is the explanation");

i.e. show the full class code.. as

import com.test.BaseResponse;
import com.tngtech.archunit.junit.AnalyzeClasses;
import com.tngtech.archunit.junit.ArchTest;
import com.tngtech.archunit.junit.ArchUnitRunner;
import com.tngtech.archunit.lang.ArchRule;
import org.junit.runner.RunWith;

import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.methods;

@RunWith(ArchUnitRunner.class)
@AnalyzeClasses(packages = "com.test.controllers")
public final class ControllerMethodReturnTypeTest
{
    @ArchTest
    public ArchRule controller_public_methods_should_return = methods().that()
								       .areDeclaredInClassesThat()
								       .resideInAPackage("..controllers..")
								       .and()
								       .arePublic()
								       .should()
								       .haveRawReturnType(BaseResponse.class)
								       .because("here is the explanation");
}

This way teaching arch rule can be two way.. especially from result pass or fail can be much clean if we were to understand the archunit rules from test results view.

[hankem]

While this is an interesting idea, I fear that this is (far) beyond the scope of ArchUnit: 😅 Your test report is probably generated by Gradle; a report generated by Maven or another build tool (including IDEs) may be different. java.lang.AssertionError cannot carry meta-data that might allow ArchUnit to communicate such information to the build tool, not even speaking of the case of a successful test, when there is no test failure exception.

So sorry; I don't think that this can be realized within ArchUnit.

[nagkumar]

Sure, this pi-test which is a mutating testing framework as similar function, I think they have implemented it themselves part of the plugin approach..

When click companyfixed.java, it opens up the source code

[codecholeric]

But the report you're showing is generated by Gradle, so I don't know if it's even possible to adjust it and even if, it would be a Gradle specific implementation, right? We could write our own test report like PIT, but that would mean reimplementing everything that the Gradle report already offers and then maintaining this over time. To me from a benefit vs costs point of view this would make no sense :man_shrugging: Or do you have any suggestion on how to achieve what you want with a reasonable effort?

[nagkumar]

I don't think this report is the default thing that gets generated by Gradle.. I can see pitest source code to generate report at

https://github.com/hcoles/pitest/tree/master/pitest-html-report/src/main/java/org/pitest/mutationtest/report/html

[codecholeric]

Yes, but the report you're showing at the beginning of this issue, i.e. the one currently generated for ArchUnit tests, this is generated by Gradle. ArchUnit has no custom html generator to create any html report and I'm also not convinced of the return of invest here. I agree that there are many nice to haves, but for me this doesn't justify the effort to reimplement everything ourselves yet, when there is a perfectly good test report generated by Gradle that is just missing this one convenience feature of showing the rules code inline vs. you have to navigate to the rules code yourself. Because, creating such an html report from scratch doesn't come for free right? It's quite some implementation effort. Then there are now two html reports (the one from Gradle and the one from ArchUnit) which might confuse users. Then we have to maintain this custom html report, fix bugs, update it with the html spec, etc. For me if I compare this against other features we could implement, it just doesn't cut it :man_shrugging: