What's new: Testability Enhancements

0:07 Hello and welcome to this session of testability improvements. My name is Thomas and I'm joined here today by Thaddius. We are engineers on the Business Central team focused on improving the developer tooling. So let's get started. For today's agenda, we're going to keep it short, going to keep it to datadriven testing and test handlers. and what that is we'll get into in detail. So first up datadriven testing. Datadriven testing is not a new concept. Um most of you probably already have been familiar with it for a long time but finally we have introduced it into ALE and this allows you for having just a single test point but with testing it with multiple data sets.

0:51 So this gives you the flexibility of quickly uh adding more tests by simply adding more uh data points into your data set. And in the era of AI features, this is so critical that we can broaden our test um scope to such an extent that we gain the trust uh and confidence in our AI features. So how we actually doing this in AL? Let's jump into a demo. Here I have my test code unit where I have a single test unit in it. Um, and you can probably already see that I have my test data set and that's the the new attribute we going to talk more about in a minute.

1:29 But first off, let's see how it looks like in the interface when we start running these tests. So right now I have my um test right here. It hasn't been run um but I don't see any test cases just yet. For that I need to run the test once and then they will all show up here all my test cases and all the features that you expect from using V studio codes test explorer is still available for all these test cases. So you can run a selective case uh selective uh set of all of the test cases. um just from those you can go in and debug them all the regular features that uh you come to love uh from the test explorer.

2:12 So let's jump back into how we are actually pulling this off in uh in in AL. Now here I have two of these where the first one is resource files. So if we go over to my list of files, the second parameter right here maps to my resource file. And my second data source is one that generates all of my test cases uh on the fly. And the number here indicates how many test cases that I want. So if we jump into and see how the actually implement this test data source, then there's an interface that we need to uh implement.

2:48 It has two functions. one that list all the test cases and the second one where you actually in construct all of the objects uh with the um test context all the test data um that you're going to run with. And one thing to note here is the second function right here returns an I test context. But when we go back into the test then we didn't see an interface of I test context. We see my own uh tailor made one here for the test case. And that's allows you to make a strongly typed interface that will give you the uh the ease of use of working with these test cases right here.

3:28 So all of this is gives you the the flexibility of implementing just the data source that you uh want and need. So right now this reads from the resource file but it could equally be reading from an AL table or your web service. Um the sky's is the limit for you here. So now with datadriven testing we saw that it was running in V studio code but not only that we also give you the possibility of running it in the AL tool and the AL MCP uh connection. Some of you have already seen that we have implemented datadriven testing in the AI test toolkit. This is not yet using these new capabilities which means that you are not able to run these from Visual Studio Code.

4:11 Um but that's just a matter of time. we are planning on migrating them to this new system. That was all I had for datadriven testing. That is over to you with test handlers. >> Thank you Thomas. So now let's talk about test handlers. So what are test handlers? So in short, test handlers are a way for us to provide test setup and tear down functionality in ALE. If you have been writing AL tests for a while, um you'll probably know that back when we had AL test runners, there were triggers that you could hook into to decide whether you should run a particular test line or not or do some setup material,

4:48 but we sort of lost that when we moved to the platform test runners. Um so we've brought that back now with test handlers and there are several different levels of granularity that we have. So you can specify logic to run before or after the test code unit runs or before and after a test procedure or even with a new datadriven test. You can have logic that executes before and after the datadriven tests. And this allows you to do things like set up the prerequisites for your test to set up some common records so that you're not duplicating them across the different test lines. Um or you can do more global things as well because we have two different types of test handlers.

5:26 We have the regular test handlers which I think of as like optin test handlers. The test code unit has to declare that it wants to use this particular test handler. But we also have these default test handlers uh or I like to think of them as global test handlers because they run on every single um test. And the good thing about these default test handlers is that it allows you to set up things like telemetry logic or if you're let's say extending some of our Microsoft features and you want to um verify that your feature you know does not break any of the common functionality that Microsoft provides.

6:03 You can add additional setup in these default test handlers and then run a Microsoft test suite so you can get more coverage that way. So let's have a look at what these test handlers look like in AL. The first thing you need to do when you're defining a test handler is that you need to register it with the system. This sort of tells the platform that um these test handlers are available for test cases to hook into. And here you can see I have two enum extensions. The first one is extending just the regular test handler enum and these are the optin test handlers.

6:38 And the second one is extending the default test handler enum and these are the ones that I was talking about earlier saying that these are the global test handlers. So for this specific test handler down here this telemetry test handler this will be run on every single test right. So whether it's provided in this app or it could even be in other apps like you know they will be run and uh but these ones these have to be opt in by the code unit itself. So let's have a look first at what this interface actually is. This itest handler interface. Um and it's basically a bunch of hooks for you to implement

7:15 before and after logic on the different granularity levels that I mentioned earlier. So here you have the on before after code unit and you have one for the procedure level and you have another one for the test case level. One thing to note here is that a lot of these have well all of these have default implementations. This means that you know if you if you're writing a test handler and it only needs to execute before or after a test code unit, you can just implement the before after test code unit and you don't have to implement the rest. So that makes the implementation simpler. So let's have a look at one of these tests here. So um on test code units now there's this new property called test handlers and this is where you register your test handler and you can have this is a comma separated list.

7:59 So you can have multiple um test handlers here. Um one interesting pattern you can use. So you might find that a lot of your test handlers uh you might only need it for a specific test code unit. So you can also have the test code unit itself implement the itest handler interface and then just register that as a test handler. Um and you know so this keeps your setup and tear down logic very close to your test code. So one thing to keep in mind is that these um test handlers are separate from the test toolkit events that are driven by AL test runners. So if you um are writing AL test now you may be familiar that we have a bunch of events that the test toolkit itself uh emits and that you can sort of like listen to and this is separate from that.

8:46 So um if you're using those you will need to migrate across to this if you want to take advantage of these functionalities. Um the other thing is that test handlers similar to the triggers we had on the testr runner level on the AL test runners prior to this um you can use test handlers to also skip certain test cases. So you can use uh so one common use case nowadays for us internally is we use it for managing token consumption. So you might want to say hey u I want you know I have this global test handler that monitors what is my token consumption for the month and if I've exceeded that limit I don't want to run these test cases because I know that they will

9:25 consume more AI credits that's one use case and you know there might be other um resources that you might want to manage and you can use test handlers for that and with that uh that concludes this presentation on the testability improvements in AL Um, I hope you enjoy using them. I hope uh that this brings more productivity to you and your org. Um, as always, like you can always reach out to us if you have bugs or any suggestions on the Microsoft AL public GitHub. Um, and with that, I want to say thank you and I hope that you have enjoyed this presentation.