Example of ArchUnit testing archunit tests itself

[nagkumar]

It would also be good to have an example of archunit, that tests archunit tests themselves, e.g I want to make sure there is one test at least against each method of the main class.. make sure unit tests are not dependent on each other unit tests etc..

The design and Architecture of the Unit Test code are equally important.

[codecholeric]

Can you elaborate a little what you mean by "good to have an example"? Do you mean you would like to see one for yourself? Or that we should add one? If it is the latter, in which form/where?

In general, the idea would be that the docs are just good enough that users are enabled to write their own rules like "every method should be called by a test" if they consider it beneficial. Because, in the end we'll never be able to cover every specific need a project might have with a similar example.

[nagkumar]

ArchUnit is testing the main code if following proper architectural guidelines.

Can ArchUnit Tests Unit TestCases themselves..

e.g rules that apply to unit tests are

1. No Unit Test should depend on another unit test created state
2. All Unit Test Classes should end or start with name Test
3. Each Method that tests main classes method abc() should be named as testAbc() etc.
4. No Test cases should be empty and it should at least one assert
5. and more...

The request is for extending ArchUnit to support Architecture and Design of Unit Tests Themselves, rather than only the main code. If such thing is possible, better to have an example for the same part of the examples github repo i.e. https://github.com/TNG/ArchUnit-Examples

[codecholeric]

But isn't writing these rules absolutely no different from writing any ordinary rule? How does it defer from writing any other rule for a specific property of my code base? The problem is that many things are highly project specific, so I'm not sure an example would help so much. E.g. "all unit test classes should end or start with name Test". What is a unit test? How do I identify such a class programmatically? That is likely very dependent on my concrete setup. For JUnit Jupiter I could look if there is any method annotated with @Test or @TestFactory or something like that. But for another test framework this might be completely different. There are a lot of generic examples of how to test x (e.g. naming conventions, annotations, packages, etc.) All that can simply be applied to test code to enforce project specific conventions, right? For example take https://github.com/TNG/ArchUnit-Examples/blob/main/example-plain/src/test/java/com/tngtech/archunit/exampletest/NamingConventionTest.java#L17, what prevents you from simply taking these examples and applying them to test naming conventions instead? ArchUnit just tests Java bytecode, there is no limitation of testing "main" classes and by default importing a package will even give you all the test classes as well. Note that there exists com.tngtech.archunit.library.GeneralCodingRules#testClassesShouldResideInTheSamePackageAsImplementation(), which is an example of a rule that tests test classes. Maybe we could add an example of using this rule?

[scelestino]

I started using ArchUnit recently, but I wanted to apply the same set of rules to several projects. What I did is creating a test library for all those rules, so they can be reused in all my projects.

So... the ArchUnit code inside the library belong to main, because is a test library... which means that I created several unit tests to check those rules. In order to do that I just created fixtures classes that I can evaluate manually.

    @Test
    void givenSingletonClass_whenItDoesntHaveInject_thenHasViolations() {
      final JavaClasses javaClasses = classFileImporter.importClasses(InvalidSingletonClass.class);
      final EvaluationResult actual = INJECT_CONSTRUCTOR_WHEN_SINGLETON_CLASS.evaluate(javaClasses);
      assertTrue(actual.hasViolation()); // probably here I should check the error message as well
    }

of course, this pattern only works because almost all my rules were written inside a library, not the main project.

[codecholeric]

You can also take a look at ArchUnit's own unit tests :slightly_smiling_face: We nowadays often just define local classes to keep everything in the test together. Like

@Test
void someTest() {
  class Allowed { /* class just defined inside of the testing method */ }
  class Violating { ... }

  new ClassFileImporter().importClasses(Alowed.class, Violated.class)
}

But of course having a little test example project also works fine...