Cloud 5 - Mysteries of Cloud Manager - Unit Tests

So I’m telling you, James, I mean, Beetlejuice is much more entertaining than any episode of Peppa Pig. You know, Darren, that’s pure blasphemy. Have you ever been to Peppa Pig World in England? It’s a much happier place than Disney or any other theme park. Come on, man. Just stop. I thought we were here to uncover the secrets of Cloud Manager. We were until you had to go and insult all the good pig fans out in the world. What are you thinking? OK. OK, fine. Let’s just stop the discussion and move on to introducing the series of mysteries of Cloud Manager. How’s Mr. Applesmith doing? Stop. Just stop. Hey, how did I get here? Testing your AEM code to make sure it’s working as intended has been a core capability in Cloud Manager and AEM as a cloud service from the beginning. I think most of the audience knows that Cloud Manager can run a litany of tests each time it deploys to make sure that your project code will not break product. Now, Brian, we can all Google why we should create unit tests and find all sorts of opinions one way or the other. However, in the context of AEM development, I would ask, what are the reasons and benefits for writing unit tests and providing vast code coverage in your project? Well, aside from the other reasons that you would Google, unit tests increase the confidence that the code that’s being deployed into AEM is going to work as expected once it’s live. When the customers write their unit tests, they provide context to our automated checks that their dev teams have actually considered the inputs and outputs and expected behavior of their deploying features. Now, the next question I’m going to ask is, well, where are you? How do you write unit tests? If you’re looking to write unit tests, the best place to start is actually some sample code generated by the architect. We can take a quick look at it here. On the left, you can see the Hello World sample sling model. On the right is unit tests. Usually unit tests sets up the test case environments that way it’s ready to go and the test itself validates that it generates the message and that some of the other properties of the sling model are actually valid. Now, once you’ve written your test cases, it’s important to also measure how much code coverage you actually have. That’s what goes into the cloud manager metrics. You can actually test or rather run your code coverage metrics locally. And you do this through the Java code coverage plugin that’s built into the Maven build for our projects. As you can see here, this is actually the default output for the Jococo plugin. It’s a bunch of XML, not really useful for us. But if you add a flag to say, hey, please generate me an HTML report, and you can see now this is the HTML output of the same content. As you can see here, all of the code that comes with the archetype is 100% code coverage, which is what we’re looking for, hopefully from a given project. Now, we know how the metrics are created. It’s important to know how to use. Code coverage is one metric for determining quality of a given project, but it’s not the only one. So other ones are, if you look here at the cloud manager pipeline output, you can see like we have code quality at the bottom of the list, not necessarily least important. Next one up is maintainability. And this is really about how well teams understand and are able to maintain their code base. Is there a Java class that has 1000 lines of code? Is there a method that has 17 if blocks? Does it recurse? Basically, how complex is your code? And that measurement will indicate to us whether or not the code is maintainable. Now, it’s not necessarily as important for us, but it is important for development teams. And they should know what these values are. Next is reliability rating. This is where we start looking at how code that’s going into AEM is going to affect the AEM environment itself. Anything that’s critical or higher is going to automatically fail the pipeline. We’re not going to pause it. We’re going to fail it to protect the environment. And this is things like basically implementing interfaces that you’re not supposed to that are part of a product and that are marked as part of the product itself. Other things, minor and major, they should still be looked at by teams because those still may have some kind of unknown impact when you’re actually in the running environment. That may cause unexpected behaviors for our customers. Finally is security vulnerabilities. These obviously would cause issues once they’re deployed. And there’s a number of them listed both on the documentation page and out there available for each that can be easily found. As you can tell, this is kind of a hot topic for me. And so I’ll just leave it with one last little bit of information. All of the custom code quality rules that are available or that are run by Cloud Manager are available on the documentation site. We also run the standard litany of SonarQube and FindBug rules against the codebase whenever we build it. Hope that helps.