Test driven development and X++

-
Test driven development (TDD) is a great way to work with unit testing in D365FO development. There are multiple benefits working with and introducing automatic tests for your code base.
  • You’ll code correctly faster, 
  • Good tests make good documentation
  • You won’t forget to write the tests
  • You’ll write more meaningful tests when you test before code
  • It makes introducing changes later in ALM easier
  • It pushes you to write cleaner code, smaller pieces of code to make testing easier. 
The principles of TDD are as follows. 
  • You are not allowed to write any production code unless it is to make a failing unit test pass.
  • You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  • You are not allowed to write any more production code than is sufficient to pass the one failing unit test. 
If followed they will ensure that the developer is either working on writing test code or business logic.

In X++ it's easy to follow these principles by coding against an interface in the business model and testing against it in the test model. This way reduce the code that is required in the business model before writing the test. 

To get started with automatic tests create a test model related to your business model. If you business logic model is called for example pekFeature the related test model would be named pekFeatureTests following the pattern of <business logic model name>Tests. Make sure that your test model references TestEssentials, this model contains the SysTestCase class that all tests need to extend.  

Writing a test is as simple as in below example. The pekCalculator class would reside in the business logic model and the related test class named Test like pekCalculatorTest would reside in the separate test model. 


Writing a test is as simple as below, start by extending SysTestCase.

Each test should be named test<description of test> and tagged with the attribute [SysTestCheckInTest] .

It's also recommended to divide each test into a Arrange, Act and Assert section to make it easier to read. Use the arrange section to setup the data and prerequisites for the test. The Act section to perform the action that is being tested and the Assert section to verify that the expected outcome was produced by the Act section. 

See my repository for examples here, https://github.com/ponekbladh/d365foblog

Comments

Post a Comment

Popular posts from this blog

How to disable auto enabled flight key using KillSwitch

-
Image
Microsoft is introducing new functionality into Dynamics 365 for Finance and Operations with flight keys in every other new release. For this they use  Flight  classes so that the changes are automatically applied and can be reversed.  Example of a flight class that control the functionality of a new set of functionality.  When a flight key that enable functionality can be found in the flight key table  SysFlighting To disable the functionality don't delete or change the enabled flag on the flight record, instead insert a KillSwitch  record. The KillSwitch record will ensure that the flighed functionality will stay disabled as long as it exist in the flight table.  In an environment that Microsoft maintain can raise a support ticket in LCS to disable specific flight keys.  SQL statement for insert the KillSwitch record.  DECLARE @flightName NVARCHAR(100) = 'WHSWorkCancelForcedFlight_KillSwitch' IF NOT EXISTS (SELECT TOP 1 1 FROM SysFlighting WHERE flightName = @flightName
Read more

Technical intro to Feature management in D365FO

-
Image
Feature management is an alternative to configuration keys for releasing and introduce a new features into D365FO.  MS is still releasing updates around the framework but the existing state as per 10.0.9 provide all we need to get started with releasing functionality that is controlled by the feature management framework.  The key to the feature framework is the feature class, in my example below see the class  pekTestingFeature. It is used as a descriptor for the feature and the flag to indicate if the feature is enabled or not. Once the class is created and compiled, users can navigate to Feature management  under System administration  and enabled/disable the feature. It is possible to make a feature enabled by default or disable the possibility to disable the feature. If the feature doesn't automatically appear, run the Check for updates button.   The feature class can be applied to menu items and menus. If enabled the menu item or menu will be visible to the
Read more

Continuous integration and deployment Power platform FinOps tweaking

-
Image
If you are working with the new unified development environments and CICD pipelines described here .  You might find the fact that we have to update the pipeline with the platform and application version annoying.  A quick way to get around this if you are using azure hosted agent pipeline as per this repo is to pull the number from the package.config and using it in the create deployable package task as per the two example tasks below.  The first powershell task will pull the version from the nuget files and save it to variable that can be reused in later tasks within the job. 
Read more