Two days ago, my fellow MVP Mike Glue wrote a blog post about multi-level dependencies between AL extensions.
Here he wrote that if you had an extension (i.e. a common library) which was used by another extension, then if you wanted to test the extension in a test app, then you also need to include the library as a dependency in the test app. So instead of a simple hierarchy of apps, then lower level apps also needed to include the higher levels apps as dependencies.
I didn't really like this, it messed up how I had expected this to work.
I therefor decided to test this on my own, and can say it very clear, that:
You need to specify dependencies, if you make direct use of the functionality in a higher-level extension.
If the lower level extension only makes indirect usage of functionality in an extension on a higher level, than its parent, then dependency is not required to be specified.
In my situation it allowed me to run my test and do exactly what I wanted. I could use a page running a table from the common library and I could even get the results of messages shown by the library codeunits. By using testpages, I was able to avoid referencing directly to anything in the library app.
If my main app had been a table and page extension, extending an object in the library app with new fields, then it would have been different. In that case, if I would not be able to see the fields added from the test app, unless I also specified dependency to the library app.
The question is really: Does it really matter that much?
No matter if you specify the dependency or not, then it exists. You can't really do much with lower-level extensions, unless the higher-level extensions are also present. Not specifying them is almost like leaving out important information to the next developer who is asked to modify the extension. You may be able compile it, without all the symbols. But you would not be able to run or test it.
On the other hand, then if you specify the dependency in the app.json, then you may (by accident?) happen create a binding to the library app, that you otherwise would have created. Always remember to keep it as simple as possible, with the absolute minimal number of bindings between extensions.
So, everything is still as I assumed it to be.
The one thing I would to be different here, is that testing multi-level apps is a pain. Each time you need to republish, then all apps depending on that app, must also be uninstalled.
How did I test it?
Taking a test-driven development approach, I started by writing the tests. This way anyone in doubt would be able to run the tests on their own. With my assumption that I didn't have to have my library app as a dependency, I listed a few scenarios I would be testing.
Scenario 1: Can I open a page using the table from the library app?
Given: I use a page from the main app showing a table from the library app.
When: I do not have a direct dependency to the library app.
Then: I must be able to open the page using a testpage.
Scenario 2: Can I create a record in the library app using a testpage?
Given: I use a page from the main app showing a table from the library app.
When: I do not have a direct dependency to the library app.
Then: I must be able to create a record open the page with a testpage.
Scenario 3: Can I use an action on the page calling a function from the library app?
Given: I use a page from the main app showing a table from the library app
When: I do not have a direct dependency to the library app
Then: I must be able to use an action calling a function from the library app.
Scenario 4: Can I use a table from the library app directly in my test?
Given: I use at table from the library app
When: I do not have a direct dependency to the library app
Then: I must get an error.
I setup a VS Code workspace with three individual AL project:
- Project 1 would be the library app. It would contain a codeunit with a simple function.
No dependencies.
- Project 2 would be the main app. That would contain a page, using the table from my library.
Dependency on project 1. - Finally, it would have a test app or Project 3. Here I would be having my tests.
Dependency on project 2.
If you want to try to test it yourself, then go to:
https://github.com/epernst/AL-multi-dependency
When you go to GitHub, then you find a description in the readme.md, on how to try it. I've used a local container with the latest public Business Central Sandbox release.