Cloud 5 - Mysteries of Cloud Manager - Unit Tests

Transcript

So I’m telling you, James, I mean, Beetlejuice is much more entertaining - than any episode of Peppa Pig. You know, Darin, 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 do you think. OK. Fine. Let’s just stop the discussion and move on - to introducing the series at hand: mysteries of cloud manager. How’s Mr Applesmith doing? Stop. Just stop.

Hey. How do 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 the product. Now, Bryan, - 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 its meant to 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 archetype Take a quick look at it here on the left and see the Hello World - sample selling model. On the right is the unit test. Essentially, the test sets up - the test case environments. That way you’re ready to go. - And the test itself validates that. It generates the message and that some of the other properties - of this sling model are actually valid. Now, once you’ve written - your test cases, its important to also measure - how much code coverage you actually have as - what goes into the club manager metrics. You can actually test or rather run your coverage metrics locally. And you do this through the Java code - coverage plug in is built into the maven profile - and build for projects. As you see here., this is actually - the default output for the JaCoCo plug in. This is just a bunch of xml - – not really useful for us. But if you add applied to say, hey, - generate me some html report and you can see now this is the HTML - output of the same content and as you can see here. All the code that comes to the archetype is 100% code covered - which is what we’re looking for hopefully from a given project We know that how the metrics are created - it’s important to know how to used 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 at the bottom of the list. But not necessarily the 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 a thousand 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 this 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 as critical or higher is going - to automatically fail the pipeline. So I’m going to pause it. We’re going to fail it - to protect the environment. And these are things - like basically implementing interfaces that you’re not supposed to - that are part of the 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. And for our customers. And finally is security vulnerabilities. These obviously would cause issues - once they are deployed, and there’s a number of them listed both on the documentation page - and other available for a to be 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. All of the custom code quality rules - that are available or that are run by cloud manager - are available on documentation site. We also run the standard litany of SonarQube - and find bug rules against the code base. One level we do hope that helps.