initial draft for unit tests for software architecture using ArchUnit

[akinwale-habibullah]

Please read through the writing guide before submitting a pull request and go through this checklist (at least for your first article).

Feel free to raise the pull request even if the checklist hasn't been worked through, yet, to take advantage of the online preview that is generated for each pull request (see "deploy/netlify" under "Show all checks" in your pull request). But please only flag it to be reviewed by your editor after going through the checklist.

Review

• you have reviewed the text a day after finishing it (you'd be surprised how many errors you can avoid by just getting some distance to what you've written)

Content

• the article explains why and not only how
• (half-)sentences that express a meaningful idea that is understandable by itself own are bold to allow quick scanning of the text
• the text has been checked with Grammarly (the free tier is enough)

Text

• the text is conversational ("we" instead of "you", easy language)
• there are no "walls of text" (short sentences, short paragraphs with a single idea)
• the text is inclusive ("the developers" and "they" instead of "the developer" and "he/she")
• the text uses active voice instead of passive voice
• names are spelled consistently throughout the article (correct uppercase / lowercase)
• file names and variables are highlighted as code

Structure

• the article has a short intro before the first headline
• by reading the table of contents (TOC) alone, I get a sense of the "story" of the article (check the TOC in the preview after raising the PR or by starting the blog locally on your machine)
• if using sub-headlines, there's at least two sub-headlines below a main-headline
• headlines are consistent throughout the article (same level of abstraction, same style - if one headline starts with a verb in imperative form, the other headlines on the same level should probably, too)

Code Examples

• code examples are introduced with a ":" and explained below the code example
• code examples are formatted to avoid horizontal scrolling (manual line breaks and 2-spaces indentation)

[thombergs]

As a user of ArchUnit, this is not the most important fact about ArchUnit. I don't really care about the "layering" of ArchUnit itself. I care about learning which use cases I can use it for and how to use it. Can you rewrite the "What is ArchUnit" section to start with a complete example and then explaining it? Potentially after this, you can explain about the layering.

[thombergs]

Please combine all three code examples in this section to a single one. Start the section with a sentence about what ArchUnit is, then show the code example, then explain the code example. That's the best way to introduce ArchUnit to the readers.

[thombergs]

You're assuming the reader knows what Moduliths is ... please don't do that.

In general, this section is rather weak. As a reader, I don't really learn from this section what I can do with ArchUnit. I would like to see a couple subsections in this section, each explaining a certain use case in a sentence or two.

[thombergs]

The part of this article about creating a new Spring Boot application takes up over 50% of the article. This article is about ArchUnit and not Spring Boot.

I think we can remove the whole start.spring.io stuff and just show some very simple example classes that have all the features you need for the use cases you're showing. Instead of the Spring Boot stuff, feel free to add more than the two example ArchUnit use cases.

I also suggest to put the code examples directly into the use case sections. I.e. In the section "Test to check repositories are only accessed by services", start with showing two very simple service and repository classes, and then show the ArchUnit test.