Unit testing is an art – an art that doesn’t need to be confined to boundaries drawn decades back. AEM has made unit testing even more tough with its evolution and people are still trying to find the best fit aka what will work for them.
This article tries to explain some of my thoughts and what ways i would like to tackle unit testing in AEM and it’s not traditional in any ways.
I dont think there is one right way of doing it and this is just a beginning….
The journey was nothing but painful all along the way. It took me 5 hours to do what should have been a few minutes job. The Site developer had the code up and running in a HTML file in a browser and all I had to do was to make it work “as is” within CQ. It seemed like the Force of Nature were working against me and everything I did, had a problem in it. I finally got it up and running (the designs done match off as is still), but it was excruciating pain.
The AEM workflow problem is not really an inefficiency in the handover of HTMLs to CQ developers but how we should have been writing the code to begin with. We start here by seeing where the problem starts and how the code has been written. Unfortunately, we do see the OOTB Code in AEM as provided by Adobe itself are not coded to solve the problem. When I speak with Adobe they make it clear that these are reference sites and are to used as “Self-learning” but little did they know at the time that people will take this a practice and convert this into a culture.
What I want to do here is to compare 3 workflows and see what each one has to offer and what’s the best possible way to remove this inefficiency or improve productivity.
1. Follow the current set of technologies JSP-Java but change the way of working aka different set of tools, trainings and processes
2. Use Sightly ~ the new templating language pushed by AEM
3. Use other templating languages like handlebars or angular which are more platform agnostic and goes beyond just CMS and AEM (old school application development also fits)
If you ever have designed or want to design a platform/site that needs to support some steep non-functional requirements like 1 Billion hits, then you have to revert to using cache as a key part of the framework. Cache as we have known it back in the days is not longer just plugging in a library and start writing to it. There is a lot more to it when we talk in context of a Digital Media platform and how you deal with very high loads. This article will talk about principles that will help you design for Performance, Scale and Availability. This article focuses on Adobe AEM however, the principle discussed are applicable in context of Digital Platform as well.
To sum it up in plain english – Not a lot of rope to hang off of; very little use cases to use and not exciting me as much.
For anything that is enterprise or platform(ish), I won’t go for this. The technical overhead that this framework and what it solves for is not worth the ROI of managing another framework. If I’d come across strongly types content-types, I would consider to use this. The ultimate tie breaker would be how how many of the content-types need to be displayed “as-is”. If all i had to show are several compositions of data (search or what have you) maybe not. But, definitely something to consider
CQ54 is not a a typical RDBMS where I can model a set of relationships in table and soon a pretty picture starts to present itself. CQ54 stores everything in its content repository (CRX) as nodes which follow an entirely different data model i.e. Hierarchical Structure. My experience with hierarchical databases has been with day… Read More »
I heard about OSGI sometime early last year, but I did not care about it – it meant start thinking about a new way of development and deployment (thats what I heard from my friends) and I did not want to learn something else when Spring worked great for me. And, my colleagues who spoke… Read More »