I recently came across this cool tool http://www.stackifier.com/ which allows you to make so much sense out of your stack traces. Once I have locked on a stack I want to look at, this tool makes it so much easier.
We will see how this goes. But, for now the 5 rules for quality for me stand even today are:
– Deliver an artifact and ensure no one can find a defect;
– I can refactor the code knowing it won’t break anything;
– Code commits work like a charm and i can deliver code in environments quickly and with certainly;
– When I send this application to my dear friends in operation, they don’t hate and curse me;
– Quality meant, once my work is done it’s done
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).
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?
The key words are not very common and not a lot of people will see my content as #1, but it’s a mini victory for me to be able to get ranked #1 on a content and not having keywords that has my or my blog name in search terms.
We have been trying to find the right mix of unit testing (Automated) in our project, and I have been looking at various options that Sling has to offer. This was done for development of AEM based projects. I tried to follow a few articles to help me get started and each one of those
In the current world of marketing, where we have clients who want to run campaigns in next 2 weeks, we can’t be slow in how soon we release code. You can only be relevant in the industry if you can move quickly, achieve the Continuous Delivery or at least reach a point when you can get releases out in production with a reasonable speed. Those days where releases used to happen once every 6 months are gone; or at least gone in the environment/market I am operating.
We have to have Self Testing Code, We have to Unit Test, We have to have feedback loops and We have to have feedback loop as soon as possible. There is no avoidance; let’s understand and embrace Or be extinct in a few years.
Not doing Unit Testing (again not saying “automated”), is like someone telling me – Kapil, you are driving to go to your wedding and you are late and now you have to drive faster. But, instead of putting in a few more airbags and giving you better set of wheels, better brakes; We are going to take the 1 Air Bag you have today and also replace your wheels with an older set. Now, go drive else you will not get married. What do you think I would do – Drive faster and risk my life or start driving even slower because I hope that my would be wife loves enough to know that I had no option but to drive slowly. Well you get the point – While I may get married, She is going to stay mad at me for a very long time for ruining her perfect day.
For many years now, I have always found myself going back to TestNG whenever it comes to doing Unit Testing with Java Code. Everytime, I picked up TestNG, people have asked me why do I go over to TestNG especially with JUnit is provided by the default development environment like Eclipse or Maven. Continuing the