Does testing really pay off in the World of software development?
As software developers, we are constantly hounded about the importance of automated testing. We hear diatribes about test driven development, evangelist who swear by unit testing, and coders who claim testing has changed how they work. By now most people in the industry would agree there is a high level of credence to the importance for this type of testing. What I find surprising, despite the apparent benefits, is that most companies don’t do it; and in many cases it is the same who swear by it who aren’t doing it.
So why aren’t more companies utilizing automated testing in their software development? For starters, it takes more time. Of course, it’s easier to write code without companion unit tests for every method created. Writing tests often means writing as much or perhaps more lines of code than the actual solution. With deadlines looming, it is hard to justify this added effort and our tendency is to just get the application working.
Creating unit tests is hard!
Many times, it is challenge enough to just come up with the logic necessary to build an application. Couple that with factoring your code so that it can be easily tested makes the coding effort doubly as hard. One must consider potentially thorny concepts such as interfaces, dependency injection, and mocking. Questions arise such as what to test, how much coverage is preferred, or whether we care to distinguish between pure unit tests or integration tests.
Testing can also be distracting; it’s easy to lose sight of the true goal when you are worried about constructing the perfect test framework. No amount of testing, however, can overcome a solution that fails to meet its original requirements. While on the topic of requirements, with the popularity of agile methodologies, functional requirements are often more fluid. This flexibility in scope potentially sets us up for not only re-writing code, but also re-writing tests to match. Our once perfect suite of test cases can easily become stale.
Despite all the added complexities, why is automated testing now more important than ever? There are two significant reasons why automated testing has become so crucial in the software development lifecycle. First, I point to the ‘rising cost of defects’ paradigm which illustrates the exponentially increasing cost of finding a bug later in the development cycle. A bug discovered through automated testing is far less costly than the same bug discovered during acceptance testing. Later in the process; the end user must capture, document, and submit the bug. The development team must then prioritize, assign, re-analyze, and refactor. All of this is time and money that could have been saved if detected earlier through automated testing.
The second factor that has brought about increased importance on automated testing is the rise of the agile methodology. Nearly everyone it seems is using some form of agile development practices these days. This means that deployments are happening far more frequently than would happen in the old days of ‘waterfall’. With a repetitive release cycle, it becomes paramount that testing be automated. To execute the same test repeatedly is not only tedious but also invites the possibility of excluding certain tests on future runs. Automated testing not only verifies that new code is working but helps keep us covered in terms of regression.
If you or your company are in the business of developing software, ‘test the waters’ and implement automated testing in your development operations. Despite the initial investment in skills, tooling and time, your leap of faith will become apparent as your product matures. Speaking from experience, done right, a solid framework around automated testing will pay dividends before you reach the end of your first release cycle.
If you would like more information about automated testing, or how we could help you implement testing in your development environment, contact us at CleanSlate.
On Thursday and Friday, August 4 – 5, the CleanSlate team took advantage of the Lightning Now Tour stop in Indianapolis. This tour has the goals of educating Salesforce admins, users, and developers on the Lightning Experience and walking these Salesforce professionals through the conversion process. Most Salesforce users are familiar with the Classic user interface (UI) that Salesforce has had since its inception. However, this UI has not aged well and does not fit into modern design concepts. The future of Salesforce is the Salesforce1 mobile app, as well as the Lightning Experience.
You might be asking, “What is Lightning UI?” Lightning is an efficiency-driven workspace that uses activity-oriented design concepts to ensure that Salesforce professionals of all experience levels are able to quickly and easily complete their tasks within their Salesforce Orgs. In fact, Salesforce has reported that the Lightning UI provides a 41% more efficient workspace for those Orgs and users that have made the leap.
During the first day of the Lightning Now Tour, the presenters discussed the Lightning-enabled features that are available as of the summer 2017 release, along with the roadmap for features that will be available for future releases. Salesforce has posted a portion of the roadmap (from spring 2017 through winter 2018 and beyond) here.
Throughout the second day of the tour, the participants were shown and practiced the skills necessary to convert and properly implement Lightning within their own Orgs. The team worked through two Trailheads (To learn more about Trailhead, please see our previous blog post on this fantastic and free tool provided by Salesforce. The progress of steps in these projects gave the participants a better understanding of not only the overall Lightning Experience but also the process for converting Salesforce Orgs from Classic to Lightning.
The CleanSlate team concluded that the migration from Classic to Lightning is possible for all Salesforce Orgs excepting only those with a considerable amount of custom Apex development. To see how the CleanSlate team can help you make the most out of your Salesforce Org, drop us a message!
Salesforce wants you to be more secure…
On July 22, 2017 Salesforce will officially end support for any integrated connections that utilize the TLS 1.0 protocol. This applies to all browsers, mobile devices, and any integrations with Salesforce that utilize TLS 1.0. Salesforce will require at least TLS 1.1.
So, what is TLS?!? Well, TLS stands for Transport Layer Security. TLS is a cryptographic protocol that provides communications security over a computer network. Essentially, it is the means by which two computers securely interact; whether that’s you visiting a website or Salesforce interacting with an external application. The next question, logically, is then “Why is Salesforce moving on from TLS 1.0?”. The short answer is that the 1.0 protocol is almost 20 years old with known exploits and there are newer, more secure versions available.
Salesforce is not alone in this move. In June 2016, the Payment Card Industry updated their Data Security Standard (PCI DSS) to require TLS 1.1 or higher as part of their compliance check. PCI made this move specifically in response to the POODLE exploit (a.k.a., the man-in-the-middle exploit) which was found to impact SSL 3.0 and TLS 1.0; although this exploit also was found to impact servers with improperly configured TLS 1.1 and 1.2 checks.
How does this affect you and your Salesforce org?
If your organization has any secure integrations that is exchanging data between Salesforce and 3rd party applications, you need to ensure TLS 1.0 is disabled prior to Salesforce discontinuing this protocol. This will affect both native desktop integrations as well as custom developed mobile applications.
Salesforce is providing a few basic resources to assist customer admins and developers with making this move including:
CleanSlate’s team of highly skilled resources can help you determine what changes need to be made to your Salesforce org, connected apps, and infrastructure to keep your integrated business processes moving through this change. To see how drop us a message!
Out with the old and in with the new!
This saying is especially true in Salesforce. If you’re like me, you’re probably just now getting used to the new functionality that came with the Winter 2017 release. (more…)
Through conversations with many of our Salesforce clients, it has become clear that many people don’t know about the availability of free Salesforce training. Let’s reiterate that: FREE. SALESFORCE. TRAINING.
The free training is available to any Salesforce user, and can be as immersive as you want it to be; whether that’s a shallow dive into basic Sales Cloud functionality or deep dive into Heroku development.
Salesforce offers this training via a site called Trailhead. Trailhead structures their training in a variety of different ways: Trails (Admin, User, Developer, etc.), Modules (specific topic areas), Projects (used to reinforce the training), and Superbadges (allows the application of training). A “badge” is provided after the completion of each Trail, Module, Project, or Superbadge. These provide proof of your experience and knowledge of each subject area in the Salesforce ecosphere. In addition to the badges, you accumulate points, which provides a gamification aspect to make it more fun (we compare point totals internally).
The Trailhead courses are often coupled with a development Salesforce org which is a limited-use but full-featured version of Salesforce that you can use as a sandbox to build whatever you want in Salesforce. These, too, are free to obtain and use. And when used in conjunction with Trailhead courses, users are given hands-on experience with Salesforce.
If you’re looking for Salesforce training, look no further than Trailhead. It’s the best resource you’ll find—and it won’t cost you a nickel.