Cloud 5 - Mysteries of Cloud Manager - Functional Tests

Transcript

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 the 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, Bryan? 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 think or 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 AEM environment - that you saw in that sling model that was fake, it was really just a - 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 selectors? Is it not responding to things - it’s not supposed to respond to? You can’t do that with the unit test. 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 the monitoring - for the actions that AEM takes once the event is being processed. You can’t do that in a unit test. That’s - what the functional test can look like. When should you create functional tests? Basically, any time - a team is creating a feature or capability that expects AEM to be running - and in the running environment, you should be creating a functional test - for that requirement. These tests actually also provide a great regression - check during 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 the unit test, you can actually find - a few test cases in AEM archetype. They are generated by - just generating a new project. If you look here, - this is the get page integration test. It basically sets up a communication - to in a running AEM environment and then gets a few of the product pages - right out of the system. So you can validate that 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 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 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 and they want to validate those changes - during every deployment. You can also actually test things - like dialog 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 test projects in 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 a cloud manager for a pipeline run.