Description
Catch up on this webinar with Kevin Boyle, Gearset’s CEO, where he covers testing best practices and gives practical tips you can use to ensure your tests actually help you and don’t rot into a maintenance headache.
Salesforce allows us to build apps that drive every part of our organization, from CRM and sales through to HR and service desk. Having responsibility for these critical apps means it’s important that we’re able to make changes to our code with confidence — great tests that protect us as we develop give us that confidence. Writing tests that get you the magic 75% is easy, but writing great tests that help protect you as you work is a real skill!
Gearset includes a completely free Salesforce test automation feature that can help ensure you are always aware of the status of your tests.
Learn more:
Transcript
Hi, everybody. Welcome to today's webinar on Salesforce testing and best practice.
Let's start in just one or two seconds to see a few more people joining.
Okay, so as I said, welcome to today's webinar.
As you can see at the top there, there's a link to a Google Slides URL. If you type that, you can ask us questions as we go through. Today's webinar is all about testing and, Salesforce testing best practice. So what we're trying to give you is a few tips and a few, techniques you can bring into your testing, to make it better.
Introductions to begin with.
So I'm Kevin. I'm the CEO of Gearset. Gearset is our release management solution for Salesforce.
Helps you manage your releases and deployments between, your different developers, between development, QA, UAT, and production, and does a whole lot more besides. One other thing is test monitoring, which we'll come on to.
If you wanna connect with me later, you can do so on Twitter or LinkedIn or just reach out to me via the Gearset website.
Roped in an expert with me today as well. So Hi. I'm Nigel.
I'm a lead Salesforce Developer here at Redgate.
We, put Salesforce in probably a couple years ago now, with a big integration with our back end systems. Again, my details are on the page.
Cool. Thanks.
So let's get started.
So not that you guys need it, but a little bit of background on Salesforce. Salesforce is one of the companies that's really had a massive impact in the last decade. Pioneered software as a service before it was fashionable to do so.
It has enabled many companies around the world to see rapid operational and sales growth.
As developers and admins, it's fair to say that Salesforce doesn't follow the traditional ALM workflow.
And it brings a few fresh ideas to development.
So there's very little use of source control, I would say, across, the Salesforce ecosystem.
Most people work directly in orgs. This allows them to be very efficient and see changes quickly.
And it allows orgs, to evolve quickly and organically.
This means that, small development or admin teams can support really large user bases, and this would be very difficult to do on other platforms.
One of the things that Salesforce is challenging when it comes to is managing change.
So Salesforce is a business critical platform and, you know, is maybe the most business critical platform in the world as we saw last week when they had a slight outage.
And managing change in that is important. If your Salesforce org goes down, that costs your business real money.
Some of the things that make, change challenging is the lack of rollback. So when you make a change, it's, important, to understand the consequences of that change because it's it's tricky to rollback. This requires discipline on the part of developers and admins to manage that change effectively and prevent bugs from creeping in. But Salesforce encourages end users to make changes directly in orgs.
That's the power of it. That's, you know, that's what we all love about it so much. So how do you balance all of these things? And one of the best ways of balancing it is to have very solid tests.
Having great tests protects you from disaster and allows you to make those changes directly in production production knowing there's a safety net.
So why do we test? Well, unfortunately for most of us, the reason is because Salesforce makes us. So Salesforce enforce a requirement to have tests as you move from, sandbox to production, and they have this further requirement to have seventy five percent code coverage.
So for a lot of developers and admins out there, unfortunately, they see testing as this thing they have to do just to get Salesforce to get off their back.
Why should we test?
It's really to protect your investment against changes later, erroneous changes later. So you wanna be able to make changes in the future and do so confidently, even if they're your own changes. So we've all written some code and then, you know, six months or a year later, had to change it. Couldn't quite remember what we did the first time or why we did it the way we did it. And bugs can creep in. So tests and good tests in particular can really help with that.
It'll help you accurately represent business requirements. So the best way to really know if, you've encoded a business rule or some logic properly is by trying to test it, by trying to break it, by breaking your assumptions, around the code that you've written. And tests provide a very great way to do that.
And something that's a little bit unique to Salesforce is that it helps Salesforce reliably update orgs during platform releases. They run all of our tests before they do their updates. That's great for us because they know if they have, introduced bugs on their end. That's great for us because we know that when Salesforce updates one of our orgs, if our tests don't pass, that's great. We'll have no problems.
So some of the benefits of good tests. As I said, you get to catch problems early while they're easy to fix.
So hopefully you get that instant feedback. You're making that change. You get the notification from your test framework saying that test or an assumption or trip wire has been tripped, and your head is in the space. You understand the rules. You understand what you're doing, and you and you get to fix it there and then.
Proves our code works, which is fantastic and keeps us honest. So we have to really be very concrete and very specific about what our code does and what it doesn't do. And all of that allows us to reduce the risk of change. So we can make sweeping or large changes to production orgs, and we can trust that if our tests pass, they tell us the changes, see if we can roll that into production, and our sales teams and our service teams and our marketing teams won't be affected.
One of the great things about tests is because they're, at least, good tests, they're deterministic, we can just run them again and again, and we can know that if, if they pass in the future, then then everything is still good.
But not all tests are good tests, and I'm sure we've all seen plenty of bad tests, out in the wild. Bad tests are worse than no tests at all. Often they provide an absolute maintenance headache. You try to make a small change and all of your tests start failing in random ways that you can't understand, random assertions that don't have good messages, and they just become a burden.
As I said, genuinely, having bad tests is worse than having no tests because they provide you with a false sense of security. But if they don't test to protect the things you care most about, then, you know, you you're you're you think you're safe, but you're but you're not.
Of course, you may just be testing the the wrong behavior. Some people will write the code first and then write the test afterwards to make that code pass just to just to verify the behavior for what they have written without truly thinking about the business rules or the business logic that they're trying to encode.
And they can stagnate or become blockers to deployments.
So, again, more often badly written tests, but all tests to a degree.
Things change in production, our assumptions change, our business requirements, our business rules change, business process changes, and those tests can stagnate or hurt deployments in the future.
So I'll hand over to Nigel now. He'll go through some of the best practice for Salesforce unit tests.
Hi. So, these are a few things we've come up with over the last couple of years. When we started in Salesforce development, we are pretty green. We're all used to writing new tests in in our in our c sharp code or whatever.
But at least and if you Google around for unit test best practice, you'll see a whole wealth of information on the on the Internet for these things. So I wanna focus on on on five, things we've come up with as Salesforce testing in particular.
The first one is isolation. A unit test should only test, like, the smallest amount of code possible. And to do that properly, you need to isolate it, make sure it's only getting, just just type in the bit of credit you wanna do. So you only want data applicable for that test. And one thing in Salesforce is if you have, sealed data equals true on your test, then it can see the whole org data.
So it's always worth explicitly putting on sealed data equals false in your test classes at the stop start of them. It is the default now. It hasn't always been. But if you put it out there, it makes it explicitly clear to everyone if this comes in the future. The way you do this is if, otherwise, when you move from your sandbox test to your production organization, suddenly your test failed because the data's different in this in the production, or if an end user makes changes to it, data in the end, your test start failing. So whenever you can, turn off your data.
The second one is, is the arrange act assert. This is, again, a standard for unit tests in all code, but even more so in Salesforce to get the data set up properly.
So you can see on the left here, we have the first three lines there, setting up the data correctly, getting it right. And, again, we've pulled out the actual creation data to a separate method to make it clearer so your text is compact it's it's easy to read when you come into it it's very obvious.
There's no data creation in a separate method. Then you act on it where we do the update here and then afterwards make sure you would assert. A test doesn't assert or check something's correct is not a test at all. I have seen people in the past where they actually just made a test. They did the test called test for code coverage, and it was a test which just actually becomes some code, gave you the coverage, but didn't actually check what it was doing was correct, and therefore it's utterly useless and provides you that false sense of security that Kevin mentioned earlier. So always make sure arrange, act, assert.
A third thing is to make sure you have some test running as real user profiles. Apex code runs in the system level, can see all the all the properties and things. When your users are actually using the system, they're using it as as they see it. So make sure if you want a sales user to do something and they're running on a standard profile, have a test that runs as a standard profile.
Again, you can see how we've done this here. We have a create user method on the right hand side here. Just set so guess the profile standard user, create some some test user in that. When we come back into it, we can then act on that u on act on the data as that particular user and, again, assert at the end that whatever testing makes makes sense of it.
In this case, we're testing the user can can see the email or contact.
The third thing for Salesforce is make sure you use the test start test and test stop test. These again so you go back now the original test. I missed it off for for for brevity on the other test ones. This is the original test again, and you can see we do the arrange first of all, set your data up, test dot start test.
This gives you a new set of governor limits when you're doing the acting. So, you know, in Salesforce, Apex, you will have limits on CPU time, how many statements you can actually on the database, a whole raft of things. Test dot start test resets that, gives you a whole new limits for your for your actual test to run on. Do whatever you have to do, and then stop test.
This does two things. First of all, it puts you back to the original government limits. So you you can now carry on doing more stuff like before. But, also, we'll run anything that's been asynchronous.
So we have some code normalization whereby you do something, you commit a you add a new lead, you add a new contact or something. We have some future methods which should call from that, which doesn't need in the future. In the test environment, we can't we don't wanna wait for that. So in test dot stop test means that I execute anything in the future now, then I can assert that that future stuff's also worked.
I can test my future methods as well using this method.
And the last one we want to go for is make sure you always exercise your triggers in bulk.
Again, for doing testing functionality, just send a single object for your triggers, make sure they all work fine. But at least have one test per trigger, which is called calling it with more than one object. Triggers can be called with more than one object all the time, so make sure you send aim for about ten or twenty I've put down here. You're not you're testing here that your triggers work with more than one object. Make sure you code written separately. It doesn't rely on any statics or anything that's the same between object and object to object.
The reason you don't want you don't want to do too many on these things, you're not testing the limits here. Sandboxes tend to run on slow machines. We've seen sandboxes time out when production will run fine. So you're not trying to stress it out because your sandbox will start failing. Make sure you do just make sure that your test works.
Thanks, Nigel. So hopefully we're all going to take those kinds of tips and all the other best practice and start writing great tests.
But Salesforce has some challenges that are unique to that platform and even with the best structured and best, written tests in the world, there are still some problems.
One of the big problems is the lack of automation.
So that makes it very slow to get feedback on changes.
There's also this, this, obsession with correlating code coverage and the goodness of your tests. People strive for higher and higher code coverage. And code coverage is a good indicator, but it doesn't mean that you've written good tests.
Also, changes made by end users can cause silent test failures if you don't have that automation in place.
So Gearset provides an option where you can automate your unit tests.
You can set this up with just a few clicks. It doesn't take very long at all, and I'll show you in a second how to do it. It allows you to track your code coverage and test status over time.
Quickly debug failures, so when we run your tests for you every night, if there's a failure, you can really quickly see what caused that test to fail and hopefully get to the resolution more quickly.
We have full learning. So every night, we'll run your tests. If there's a failure, we'll send you or your team an email or a text message on your cell phone or we can notify you via chat or Slack.
And it allows you to track all your tests across all orgs in one place. So if you've got quite a few developer instances and sandboxes and UAT and production and there's a lot of change happening across all of those environments, this gives you one place to check all of your, tests and know what's happening.
And finally, it's completely free. So this is a feature that we've built, for the community. We think it's a great thing to run your tests and get notified. So we're giving this one way just totally free.
So let's do a demo.
So I'm going to just start at the start. I'll go to gearset dot com. So as I said, gearset is our release management service, which allows you to manage all of your releases across Salesforce. I'll just zoom in a bit because that's a little bit broken. To get started with, you click try it now, and that brings you over to the Gearset app.
You log into Gear Set with either your Salesforce credentials or your Google credentials.
I'm going to log in with Google just because that's where I have, things configured. And this takes you to the main flow in Gear Set, which is all about release management, automation around deployments, and monitoring your orgs to check for changes in configuration.
But for today's webinar, we're going to focus on the scheduled tests.
So here you can see I've got one test monitor already set up, and it tells me all of my tests are passing. But I want to show you how easy it is to set up a new test monitor.
So you notice that I was able to log in to Gear Set within about, two clicks there.
And Test Monitors are simple as well. So we select Add New Job, give it a name. So this is Test Monitor for Webinar.
Choose an organization. So I've I've already got one of my stagings. Let's just choose some dev instance and then go to the notification settings.
So I can choose if I want to send notifications in every run. So every night, I'd get that email saying, hey. All your tests have passed, or, you know, this test has started failing.
Or I can choose to only get notified when there's a a test that has failed. For now, let's leave it on every rung.
I want to get some visibility into my whole team, so I'm gonna email team at gearset dot com every time there's, a test rung.
Because it's just a dev instance, I'm not gonna sell, a sell text message. But for production, we do have that set up.
So I'm waiting for Slack. We don't really need it. But Chatter is useful just to have that ambient knowledge. So every evening, there'll be a post on Chatter telling me what my test status is.
Save that.
And here you can see it's pending first check. So this evening, that will run.
But let's look at the staging environment that I've already set up.
So it tells me my tests are passing. I can jump into the details for this org.
And here we see the result of every single test run every evening since, early February when we had this feature in in pilot.
This is interesting. So it's failed today.
If I jump in, I can see which of my tests have passed.
They're good. I can see which of my tests have failed.
So here is a test that is failed.
It's got an assert exception.
Assert exception.
We expect the accounts, at most one account executive but actually had two. So now that I know there's something wrong, I can go dig into this test, and I can see, what code change or data change introduced that bug.
So let's just jump back to the demo.
And I'll just get the questions going again.
Sorry.
Okay. So here's the questions again. So if you do have anything.
When I was preparing for this demo, I looked up some of our statistics just on how many tests we've run. And as of this morning, we just passed three hundred tests run for our users. And interestingly, twelve thousand of those had test failures.
So that's around twelve thousand tests that, twelve thousand out of three hundred thousand tests that failed that users weren't expecting.
I also reached out to some of our users to ask them for any stories if, Gear Set had told them something they weren't expecting. And we got one back from a customer where they had their tests passing every evening, it's their production org, nothing was going wrong.
And then they started seeing a failure, and the failure that they saw was that Salesforce, so you have the three large releases every year. But there are smaller releases happening all the time as well. Without making a public announcement, Salesforce subtly changed the way they handled mixed email operations and tests. So out of nowhere, their tests started failing all night. It was only thanks to Gearset that they were able to spot it right away and figure out that it was not any work that they had done that had broken the tests, but Salesforce, updating itself. That was much better for them than waiting until one of the developers fails to deploy their work and maybe deploy failing to deploy their work during a critical release window because of a subtle change inside Salesforce.
So as I alluded to during that demo, GearSat does more than just unit testing. So Salesforce, GearSat is, one of the leading release management solutions. We take a fundamentally unique or different approach to doing release management.
What Gearset has baked into it is an understanding of your Salesforce metadata. So we'll pull apart things like profiles, permission sets, and then stitch them back together to try and create packages that work first time. So no more, iteratively building a package, deploying it, watching it fail, build it, watch it fail, build it, watch it fail. Gear set gets it right first time.
It allows you to easily compare and deploy changes between orgs. It provides simple reporting and audit, automation and monitoring as I've alluded to. The other automation that we have is around, monitoring your production org for, configuration changes. So any metadata changes that happen to your production org will tell you about and notify you about again via Chatter, SMS or email.
And there's a free thirty day trial, so you can, try it out as you're trying out the the test runner.
Obviously, I'm the CEO of the company. I'm gonna say lots of nice things about Gearset, But our customers have said some really, really positive things about us as well, which you can read about on our sites. We have a few case studies and white papers that we've done with different people.
A lot of those focuses around the time savings that people have. So So you had people that were doing eight, nine, ten hour release windows, and with Gearstep, they get that down to, you know, an hour or so.
So the key takeaways from today's webinar, testing isn't optional and you shouldn't view testing as this, thing that Salesforce puts in your way that you have to try and get around.
But writing good tests have a lot of benefits.
It reduces risk, reduces risk of change. That's the primary thing it gives you. It proves your code works. It provides executable documentation. So if you've got really great tests with understood inputs and understood outputs, then that's the best way to describe what your system should be doing. And should make your life easier. Should make the lives of developers and admins everywhere a lot easier.
And Gear Sets free Test Suite automation helps with that as well.
So thank you, Adam.
Thanks for having us today, guys. There's some resources here on the Salesforce websites around how to write good unit tests, if you want to do further reading. And there's some, links to out to our blog to tell you just how to get started with, testing and why testing is important on the Salesforce platform. We'll send this an email afterwards, so don't stress about about getting these done now.
So with that, I'll lose your questions. If you open that link, Google Slides ZS4U9, We'll give you a second or two to ask a question.
Okay. Seems like we don't have any questions at the minute. If you do have any questions after the webinar, if you're watching this on YouTube later and you wanna follow-up on anything, just email us teamgearstep dot com, and I'll either answer it, or I'll also forward an agile if it's something that's beyond my, beyond my expertise.
So with that, thank you very much, guys, and, enjoy the rest of your day.
