People will soon realize that your method works (because you succeed more often) and disrupting your process makes you ineffective and no one wants to do that.
It’s interesting how when we have to select a bunch of people to be on our projects we immediately latch onto the skilled ones whether or not they are motivated and the average guys are first ones to go even if they have a vested interested in our success (as they succeed along with us).…
This article is my POV and what I want to tell the readers, and not what this reviewer thinks and what he wants to get out. This is not just an “edit” on punctuations and language but on my thoughts is my biggest deterrent on writing for any other publication and I realized that those 2 articles have been sitting in draft mode for 18 months now. It just gets “uuggghhh…”
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….
When we see a problem on a project why don’t we take the time and fix it? Why do we get afraid of telling stakeholders that something has gone wrong and we need to course correct which might lead to an increased cost or a bit of a delay in schedule?
You can write any number of scripts (manual or automated) but unless you get yourself to be in a position where you are like a user of the site you will never know if what you are testing will meet the client’s end requirements.