Cloud 5 - Mysteries of Cloud Manager - Functional Tests

And that’s it! One thing that new to AEM developers might be unaware of is the ability to run custom functional tests as part of the deployment process. These tests ensure that the quality of a function of your code versus, you know, testing methods, etc., that occur during the build process. Similar to our unit testing discussion, I mean, why should I create a bunch of functional tests? Brian, what are some of the scenarios where I would ensure that my code function is functioning as designed? Well, unit tests run in a static context. The developers are defining the inputs and they fake or, you know, mock most of all the interactions for that test case to other systems. So really, they’re effectively controlling the output as well. Even the aim environment that you saw in a Sling model, that was fake. It was really just an in-memory storage of content. Some functionality is provided, but for the most part, it’s just a bunch of mocking and hand waving. Functional tests, on the other hand, give the developers the opportunity to test things that are running in the context of AEM. They’re actually running in AEM. And so therefore, the developers can validate a number of things that are only available in that context. Here’s some examples. Did I register my servlet correctly? Is it responding to the right Sling resource? Is it responding to the right suffix or the right selector? Is it not responding to things it’s not supposed to respond to? You know, you can’t do that with unit tests. Many customers integrate their AEM instances with third party solutions. Those can’t be done during unit tests. So in a functional test, you can actually validate that that communication pathway is up and running and that the inputs and outputs and communication is working. Finally, another example is think about event handling. You know, how do you handle generating an event in AEM, processing that event and then monitoring for the actions that AEM takes once the event is being processed? You can’t do that in the unit test. That’s where functional tests come into play. When should you create functional tests? Basically, any time the team is creating a feature or capability that expects AEM to be running and they need a running environment, you should be creating a functional test for that requirement. These tests actually also provide a great regression check during the future deployments. Cool. I mean, but where do you start? I mean, how do they run? That’s a really good question. So again, with unit tests, you can actually find a few test cases in the AEM archetype. They are generated by just generating a new project. You look here, this is the Git page integration test. It basically sets up a communication to a running AEM environment and then gets a few of the product pages right out of the system. So you can validate that, you know, it has examples for basically getting pages from AEM. Now, if you notice here, the tests are actually located in source main Java and not source test Java. That’s because we don’t want them running during the test phase of the build cycle. What instead we do is we build a JAR artifact with all the dependencies in it, and Cloud Manager runs that JAR file during the functional test phase after the stage deployment. You look at here, the Cloud Manager process, there’s product functional test, and then we have our custom functional test and then custom UI testing. And that custom functional test, that’s where this JAR comes into play. Now, where can you find more examples? Actually, here, if you look at this AEM test samples project, these are the tests that are run during that product functional test. The ones here labeled smoke, those are all run during that phase. And those provide more context and more examples of how to create functional tests. What about that third step down below, the custom UI testing? Well, that is exactly like it sounds. It’s actually custom tests to validate user interface changes. This is the step that customers can place custom tests for when they want to change or modify or extend the AEM user interface. They want to validate those changes during every deployment. You can also actually test things like dialogue, creation, and author interactions on the AEM author environment. This is different from the integration test module in the sense that this is actually a Node.js based test framework. And it runs inside of a Docker container during the Cloud Manager pipeline process. Both the integration and the UI test projects and the Maven archetype output have a profile, though, that lets you run them locally if you want to see and validate your tests before they actually get put out into Cloud Manager for a pipeline run.