Testing

Adobe Experience Manager (AEM) is an enterprise web content management system that, like many other enterprise applications, is a complex piece of software to set up and configure.We can't eliminate this complexity completely, but we can reduce it for many use-cases. AEM OpenCloud is an open source project being led by Shine Solutions that automates the setup of a complete ready-to-use AEM environment in the cloud within 15 minutes.However, testing and verifying that an AEM installation is working correctly is laborious and time-consuming. Done manually, testing can certainly take longer than the 15 minutes required to actually build the environment in the first place.Fortunately, automated testing was identified early on in the project as an important part of OpenCloud's modular design, as is made clear by this diagram created by Cliff Subagio, one of the project founders:AEM OpenCloud suiteHowever, it's one thing to say that testing is important, it's another thing to actually do it. In this post I'll talk about why and how we used InSpec to implement automated testing in OpenCloud.
I was lucky enough to have the opportunity via Shine recently to attend the inaugural OWASP AppSec Day 2018 (Melbourne) at RMIT. Security professionals from around the globe gave some insightful talks into the state of secure application development in 2018. In this post I'll share you some of the key insights I gained from these talks.

Introduction

A website may have hundreds, thousands, or even millions, of public facing pages. When we are responsible for maintaining such a website, it's impractical to traverse it manually looking for broken links. We need an automated testing tool: one which can scan the whole website and log any broken links, so we can get them fixed sooner rather than later.In this blog, I am going to describe a web crawler project which can easily and efficiently achieve the goal. The primary technologies used in this project are Scrapy and Docker.
I recently had the opportunity to work for a client who wanted to develop what they termed "app indexing". What they meant by this was that they wanted their users to be directed into a specific screen of their iPhone app when they tapped on a particular Google search result. Put differently, they wanted the user to feel as if Google had returned search results specifically for their iPhone app.They also wanted to be able to send out links via email, SMS or other marketing channels. If the app was installed, opening such a link on their phone would result in the user being taken to the relevant points in the iPhone app. If the app wasn't installed then they would just be taken to the mobile website.The way this is achieved is through what Apple refer to as "Universal Links". In this post I'm going to discuss how we implemented Universal Links at a client of ours, some of the obstacles we faced, and how we overcame those obstacles.
Monkey_Office_1AWe recently introduced acceptance test driven development (ATDD) at a client. The idea was for the product owners, developers, and testers to work as a team to come up with the acceptance criteria for user stories before development begins. We adopted this approach as an attempt to increase a shared understanding of user stories, as well as a shared agreement on the definition of 'done'.As we introduced more functionality to the application, it became evident that more and more effort had to be put into regression testing prior to a software release. The application has to be supported on mobile (iOS and Android) and desktop (Safari, Chrome, Firefox, IE8 and above). Our team of 2 to 3 testers would spend up to 3 days testing for regressions! In an attempt to reduce the need for talented testers to carry out monkey work, the team began to push for a focus on automated browser-level testing.In this post I will demonstrate the acceptance testing framework we used and describe how the test suite can be tied to a Jenkins build (with a beautiful results page!).
phpclawAs a newcomer to PHP I was puzzled by how to unit test controllers and services when using Silex (if you're wondering, Silex is based on the Symfony 2 framework and draws a lot of modules from it). In this post I'll talk about my experiences getting tests going, and how you can setup your own unit tests using PHPUnit and WebTestCase. I'll start with my initial attempts to test directly against the DB, and the approach that I ultimately found most useful and practical.I've also created an example Silex project that can be used to try out the various features of PHPUnit. The only prerequisite is PHP 5.4, which comes with most modern OS's. You don't even need Apache installed to try it out!
[caption id="attachment_4529" align="alignnone" width="339"]Like two-time WWE Champion Daniel Bryan, Javascript demands respect Like two-time WWE Champion Daniel Bryan, Javascript demands respect[/caption]Yes, it's true. Javascript is so popular it can now be a full-time job. Many people used to coast through their daily jobs as a PHP, Rails, Java developer with a few $(..) statements, maybe a $('#message').hide() (or a $('#message').slideUp(); if you were hip).But these days, Javascript is coming of age. It's grown from being a scrappy little toy we have loved and abused with code like onclick="alert('...')", to be something that has grown up with us, and now appreciate. It is the only runtime language I can think of that will run on any modern processing device. It's ubiquitous and the ecosystem has evolved beyond what anyone could have imagined, with many implementations (Rhino, V8, now Nashorn) and it's very own matching server-side equal, node.js
Clock partsUnit-testing Backbone Views is hard. You need to cover enough for the test to be meaningful (for example DOM updates and server calls), without getting too tangled up in gory details. In this post I'll talk about how we use QUnit and Sinon.JS to unit-test our Backbone views.There's already material out there on using these frameworks together, so I'm not going to get into setting things up. However, having done it for a year now I feel I've learnt enough additional tips, tricks and traps to warrant sharing them with the world.This post will cover the three things you have to think about when testing Backbone Views, then talk about three strategies for simplifying your tests. I'll also share some more general thoughts on Backbone's suitableness for building large apps.
Android's built-in testing framework is lacking on a number of levels. Enter Robotium, an open-source project. Robotium connects the dots by extending Android’s testing framework and providing convenience methods to help developers rapidly create tests.In this entry I will show how Robotium can be used for data input, finding and testing views and buttons, testing between multiple activities, and testing activities with extras. I'll also show how to work around issues with race-conditions in UI tests. I have created a GitHub project with a sample application and test project.