Ludovic Meurillon Let’s unveil the captivating world of computer sciences, engineering, and Salesforce with our accomplished guest, Ludovic Meurillon. Prepare to be immersed in Ludovic’s fascinating journey from his early gaming days to becoming a software engineer at Salesforce. Discover how he navigated joining the company during the pandemic and how he’s currently thriving as a developer. Learn about the groundbreaking ApexMockery project that Ludovic and his team have been diligently working on and how it’s revolutionizing the way developers decouple their code from the database and the Salesforce platform.

We also discuss the intricacies of the Apex stub API and how it can be leveraged in Apex Mocking. You’ll understand the key distinctions between unit testing and integration testing and the array of benefits Apex Mocking offers developers. This episode is packed with knowledge and skills that will enhance your Salesforce development journey, whether you’re a seasoned developer or just getting started. 

Get ready for an enlightening deep dive into the world of Salesforce development.

Show Highlights:

  • The ApexMockery project, its development process, and its role in revolutionizing how developers decouple their code from the database and the Salesforce platform. 
  • The importance of the Apex stub API and its utilization in Apex Mocking for writing swift, efficient, and effective unit tests. 
  • The difference between unit testing and integration testing, and the benefits of Apex Mocking for developers. 
  • The evolution of the Apex Mockery library, its use in creating custom matches, and the application of the arrange, act, and assert pattern in testing. 
  • The purpose and advantages of using the Apex Mockery library in Salesforce development. 
  • The future of the Apex Mockery Library.

Links:

Episode Transcripts

Ludovic Meurillon:
I discovered computer sciences at the French High School. Yeah. I didn’t have access to the internet until 2000, 2001 I think.

Josh Birk:
That is Ludovic Meurillon, a software engineer here at Salesforce. I’m Josh Birk, your host of the Salesforce Developer Podcast, and here on the podcast you’ll hear stories and insights from developers, for developers. Today, we’re going to sit down and talk with Ludovic about a project he’s been working with a few others about Mocking Apex. However, we’re going to keep on there, whereas we often do with his early years.

Ludovic Meurillon:
It was about gaming, actually.

Josh Birk:
Of course.

Ludovic Meurillon:
Only gaming. I used to play on every console you can find in the past and I moved to personal computers with friends at the age of maybe 15, yeah.

Josh Birk:
Gotcha. PC Master Race. What was one of your first games that you played?

Ludovic Meurillon:
Well, it was Edge of Empires.

Josh Birk:
Oh, okay.

Ludovic Meurillon:
There we go. There we go. See, I’m dating myself because I’m thinking it was like the 2D version of Castle Wolfenstein or something like that. When did you first get introduced to Salesforce?
I was not too aware of Salesforce until I tried to join the company. Actually, it was the year before the COVID, so 2019 I think, yeah.

Josh Birk:
Yeah.

Ludovic Meurillon:
I was aware about the brand. I did know a few things about the company, but I didn’t know anything about products or APIs or components, anything you can do on top of the platform.

Josh Birk:
Gotcha. What was it like joining the company under COVID?

Ludovic Meurillon:
Oh, it was new for everyone. Yeah, it was a bit weird, but at the end I missed a lot, the formal onboarding you can have before that particular season, but it was okay for me. I was close to colleagues even in France, so as soon as I can I go there and see them now.

Josh Birk:
Got it. Nice. Nice. How would you describe your current job?

Ludovic Meurillon:
I’m a developer. It’s pretty simple. I’m a developer and I’m a team developer, which means that I can work alone, but I’m better at working with the team, inside a team.

Josh Birk:
When did you discover that?

Ludovic Meurillon:
As soon as I start to work for a company in 2008, I think. I’m pretty sure that it was the only way for me to be efficient to learn from others and to help others, people with my own skills and as soon as you do something in computers in the IT services, you need the feedback from other people. So you cannot stay alone for a long time.

Josh Birk:
Nice. I like that. I like that. Well, sort of speaking about that, so today we’re talking about Apex Mockery, which is a project that you have been collaborating with. Who’s all on the team right now?

Ludovic Meurillon:
Sebastian Colladon.

Josh Birk:
Gotcha. And my friend Philippe?

Ludovic Meurillon:
And your friend Philippe, yeah. Philippe Ozil.

Josh Birk:
Gotcha. Gotcha. Now, how would you describe the origin of Apex Mockery? Were you trying to solve a specific problem or was there a specific pain point that kind of came up?

Ludovic Meurillon:
As I said, I wasn’t aware of the Salesforce, how to say that, not community, but the Salesforce world of developers, Apex, any triggers, packages and so on and as soon as I started to work for Salesforce, I joined the work.com initiative that we had at this time during COVID and during that effort to deliver some value on top of the platform inside Salesforce, I had to understand how to do that as an external developer. Okay.

Josh Birk:
Gotcha.

Ludovic Meurillon:
Yeah, and we were almost six developers in my team at this time, and we had to deliver a lot of Apex code quickly, but the fact that we came from other contexts like Java backend code, like web development, any native iOS or Android apps, we had some, I don’t know how to say that, but we were used to use some tools and libraries that helped us to implement tests, decouple code in a way or another, and we missed that very quickly in Apex. So we first did some digging on the internet within the community to see what we can use. We first tried to use fflib at some point, and we choose very, very quickly to switch to our own implementation to keep things very tiny and deliver something on top of very small classes we can implement. Okay.

Josh Birk:
Just as a curiosity was fflib, because fflib is sort of the grandfather of Apex libraries, right but it’s also, it’s pretty huge. So was it that it was just kind of too big and too unwieldy or just really not getting the job done for it?

Ludovic Meurillon:
Yeah, we could have used it, I think, but the fact that it comes with a lot of overhead made the choice for us and we just put in place a very tiny solution we had to use within the team and as soon as Sebastian joined the team, he was previously in teams that were supporting customers and deploying solution at a large scale with Apex and so on and he supported that we did a very great job from his point of view and we decided to move on open sourcing it very lately, but it’s now done.

Josh Birk:
Got it. Nice. Nice. Give me the elevator pitch for Apex Mockery, describe it for me in a high level?

Ludovic Meurillon:
Yeah. To stay general, the only purpose of this library is to help you implement fast unit tests in your Apex code, which mean that you will need to decouple your actual code or any new code from the database and the platform itself and using the lib, you can do that easily or at least easier that by hand.

Josh Birk:
Nice. I think that’s a really interesting way to put it because I think people, once you get into writing proper unit tests, and we’ll get a few questions on that, but it’s pretty obvious why you want to detach that from the database because you want your unit tests to be ephemeral. You don’t want your testing to impact your actual real world data. Tell me a little bit about the importance of detaching it from the platform.

Ludovic Meurillon:
Yeah. The first important fact is that if you embed all the platform within all your tests, all your suite will become slower and you’ll have hard times to get feedbacks from your tests, which means that you won’t run them or you will skip them, or you’ll ignore any failing test during weeks, which is not the way we want it to work when we joined the Apex effort within Salesforce.

Josh Birk:
Got it. Nice. I like that because it puts kind of a human element on it. It’s like it’s not that your unit test won’t run, it’s just that you won’t run them.

Ludovic Meurillon:
Yeah and some of us were also aware of TDD, test-driven development and we are used to it for part of us, and it’s also a way to work on a daily basis. So if you don’t use that, if you are used to it and you cannot do it, it’s like you are frustrated all day long. So we had to find a solution at least to do that a few hours a day and be sure to do it.

Josh Birk:
Right. Right. Okay. So first of all, this answers is one of my upcoming questions. So you’re firmly on the side of write test first, code second, right?

Ludovic Meurillon:
Yeah. I prefer to say that I need something that that can do the job first. Even if it’s not tested, I really test to be able to build it and repeat the operation all the way, but as soon as you build stuff every day, every weeks, and with years of experience, you tend to write tests first because it’s like a natural way to do things.

Josh Birk:
Right. Right. How would you describe the characteristics of a good unit test?

Ludovic Meurillon:
To me, first it should be self-describing readable in a way or another. So if you cannot explain that to a colleague or another developer that will need to modify it, it’s like it’s a bad one. It’s also true for any other kind of test, by the way. It should be fast to run, not easy, but fast to run and it should be if you can, it should test only one purpose within your system. This is the unit part of the test, you test the unit.

Josh Birk:
Gotcha, gotcha. Now tell me a little bit, I was reading the blog post that you, and I think it was you Philippe or you and Sebastian put together, and you mentioned the range act and assert pattern. What is that and how does that fit in the unit?

Ludovic Meurillon:
Oh yeah. I’m not sure if it’s linked or not to Gherkin Syntax if you know it, the given one way to describe any specification or runable specification at least, but in the team at the first time in the team, we agreed altogether to use that pattern to describe our test. It’s also true for unit integration test or orchestration test, any test because if you do that, what you will get for free is that you will have a kind of convention around all your tests, a way to read them quickly, find the arranged step to find what your test will set up to be able to run. Okay. The asset part is the ACT part, sorry, is the tinier one, which is only doing the job you want to test. So this is the unit action you want to cover and the assert part is about doing assertions like is my output. Okay.

Josh Birk:
Right. Right. I’m trying to remember the analogy, but there’s some good ones out there when it comes to writing unit tests without assertions is basically not writing unit tests at all.

Ludovic Meurillon:
Yeah, it’s only writing scripts in that case.

Josh Birk:
Exactly. All right, well let’s say a little bit more about the library itself. First of all, it leverages the Stub API, which I’m going to admit I’m not very familiar with. What is the Apex Stub API?

Ludovic Meurillon:
Yeah, so the Stub API is basically what the platform offers you to stub any method in an Apex class, which means that you can hook any call to a method and choose what to answer or what to do instead of explicitly run it. So this is a way to plug a behavior in place of a method. You can also, I’m pretty sure, I’m not sure of that, but I’m pretty sure that you can also delegate. So let’s say you have a hook, you do something and you still run the method at the end. You can do that also, but what we did in the library is that we used the stub API capabilities to replace part of your code with the library itself to be sure that when you run a unit test, you are not involving any other class code and user class behavior. You’ll have to choose to replace them.

Josh Birk:
Got it. So this goes back to the concept of detaching it for the platform and keeping at speed, fast and efficient.

Ludovic Meurillon:
Yeah.

Josh Birk:
Got it.

Ludovic Meurillon:
And it will force you the way we implement it, it will force you to define a contract between your elements, your APEX classes and say, okay, my Apex class A is depending on B and B as a method go, so I need to stub that go method within the A tests suites just to be sure you are not involving all the code in one test.

Josh Birk:
Well, and to kind of add onto that, you also write about the difference between… Where do you say is the distinction between unit testing and say integration testing and where do those two things fit into a developer’s tool?

Ludovic Meurillon:
Yeah. The difference or my own explanation of that may be influenced by a lot of other explanation is that unit test is there to test a very specific part of your code, isolated one, something that can be moved with the code itself. You move the code, you move the test. Integration tests are more there to validate that when you integrated different classes altogether, it behaved correctly and it’s like what you are actually doing. If you do a default Apex test in the documentation, I think it’s already involving the SoCal queries on top of some Apex code. So it’s like an integration directly.

Josh Birk:
Got it. Let’s talk specifics about the library and I know this is podcast, so unfortunately we can’t hop over to the terminal, but what does Apex Mockery do to help developers get this done?

Ludovic Meurillon:
So the only purpose of the library is to offer you a way to mock, to replace method within your code using a specific static class. I don’t remember the name of the class to be honest.

Josh Birk:
That’s fine. We’ll point to the blog post. People can read it.

Ludovic Meurillon:
Exactly and as soon as you did that within your test, you are able to change the behavior of the method itself, which is considered as a dependency during the test and you will also get for free some assertions that you will be able to do on top of the method itself. Let’s say you want to validate that, I can take an example. You have an Apex class that is trying to load data from the database to do that. You have another Apex class that is loading something within the test. You can stub the entire database class and act as if you are loading something from the database, but you are only doing that within the test, which is faster.
Very, very, very faster and you can also do assertion like during my test, I code my method once I code my method with specific arguments and so on and this is where you have a value within the lib. It’s like Sin Tax, sugars to do all that stuff. That should involve a lot of overhead. If you do that by hand.

Josh Birk:
Gotcha. How would you describe, I’m assuming you’re using this in your day-to-day, how would you describe some of the advantages? Are you writing less code? Is it simply faster to write the unit test, or are you just writing faster unit tests or all of the above?

Ludovic Meurillon:
I cannot say if it’s faster, if unit tests are faster with the lib, to me, it’s not the target of the library itself. What you have, by the way, is a way to very quickly write something and a flexible way also to assert stuff, which means that you can also provide custom matches on top of your own big data model, for example. So if you want to match a very particular field within an object that were sent as an argument to your method, you can do that. Also. This is where the library is very useful to me, and this is what at the beginning, we implemented within the TM in a generic way. So this was our goal at the beginning and now this is what you have with the lib.

Josh Birk:
And this is all open source now?

Ludovic Meurillon:
Yeah, yeah. Since two months I think.

Josh Birk:
Okay. How would you see it evolving or is this put a pin on it and maintain it, or are there new features that you’re thinking about?

Ludovic Meurillon:
We are not planning to add new big features or breaking changes. The goal for us was to share that with the community. Our goal today is to go over all Apex developer, at least within Salesforce, to talk about the lib, and we will support the new Apex version and new features that could be useful within the library, but we won’t add a lot of new features. It’s finalized since we released it, and we do think that it’s enough to not be too big. One of our goal is to keep it tiny also, so if we need to add a new feature, maybe we will deliver another library to say, okay, you can cherry pick what you want depending on your needs. Yeah.

Josh Birk:
Got it. What kind of installation options are there?

Ludovic Meurillon:
I don’t remember all the installation method you can have, but you have an unlocked package available, a version one. You can also copy past all the Apex classes within your project very easily, which is a way to take library in Apex and I think it’s over. Yeah, we have a package delivered within the GitHub space. You can see it.

Josh Birk:
Okay. Is that the easiest place for people to learn more? We’ll put the blog post in the show notes, but is the GitHub repo kind of the source of learning more about it, downloading it, installing it, et cetera?

Ludovic Meurillon:
Exactly. Yeah. You can follow the blog post even if it’s not going into the EV details and if you want to know more, you definitely should go within the GitHub repository in which you will find documentation and some samples. Also, we used a lot of samples just to cover what we were doing, and now you can just check them to see if it’s easy to read what you need, et cetera.

Josh Birk:
And that’s our show. Now before we go, I did ask after Ludovic’s favorite non-technical hobby, and it turns out well, he is a little bit of an artist.

Ludovic Meurillon:
Oh, I do drawing.

Josh Birk:
Oh, nice.

Ludovic Meurillon:
Yeah. I also do photography, photo. Okay and I play a lot to video games.

Josh Birk:
What are you playing these days?

Ludovic Meurillon:
I’m currently trying to play Starfield, which is not, yeah.

Josh Birk:
Like every other person-

Ludovic Meurillon:
Exactly.

Josh Birk:
Doesn’t. I want to thank Ludovic for the great conversation information. As always, I want to thank you for listening. Now, this is actually the last episode. I’m going to be personally responsible for producing for the Salesforce Developer Podcast. I’ve moved over to admin relations and a few new challenges, and I’m handing the reigns over to the wonderful Julián Duque, who I know is going to do a great job with the show, and you’re going to have a wonderful time listening to him.
I want to thank everybody who has supported the show, who has listened to the show, has been guest on this show. It has been an absolute pleasure doing this show, and I’m very proud of it. If I’m being completely honest, it’s one of the things that got me through the pandemic, and it’s just been a source of joy. So once again, everybody, thank you for listening. If you want to learn more about this show, head on over to developer.salesforce.com/podcast where you can hear old episodes, see the show notes and links to your favorite podcast service.
And as of now, Julián’s going to start talking to you next week but everybody, thanks again and have a great day.

 Get notified of new episodes with the new Salesforce Developers Slack app.