AX Developer ALM

Cross-Post: Performance improvements that may affect test automation code

Joris dG — Tue, 08 May 2018 12:20:56 GMT

A performance improvement related to UI and data may affect test automation. This can apply to manually authored tests using form adaptors / type providers, or a recorded test where a platform or app update moves a control used in the test. For more details, please read this blog post on the community site.

Enabling X++ Code Coverage in Visual Studio and Automated Build

Joris dG — Wed, 28 Mar 2018 10:51:42 GMT

To enable code coverage for X++ code in your test automation, a few things have to be setup. Typically, more tweaking is needed since you will likely be using some platform/foundation/appsuite objects and code, and don't want code coverage to show up for those. Additionally, the X++ compiler generates some extra IL to support certain features, which can be ignored. Unfortunately there is one feature that may throw off your results, we'll talk about this further down. One important note: Code Coverage is a feature of Visual Studio Enterprise and is not available in lower SKUs. See this comparison chart under Testing Tools | Code Coverage. To get started, you can download the sample RunSettings file here: CodeCoverage You will need to update this file to include your own packages (="modules" in IL terminology). At the top of the file, you will find the following XML: .*MyPackageName.* .*MyPackageNameTest*.* You will need to replace the "MyPackageName" with the name of your package. You can add multiple lines here and use wildcards, of course. You could add Dynamics.AX.* but that would then include any and all packages under test (including Application Suite, for example). This example also shows how to exclude a package explicitly, for example in this case the test package itself. If you have multiple packages to exclude and include, you would enter it this way: .*MyPackage1.* .*MyPackage2.* .*MyPackageName1Test*.* .*MyPackageName2Test*.* To enable code coverage in Visual Studio, open the Test menu, select Test Settings and Select Test Settings File. Select your settings file. You can then run code coverage from menu Test > Analyze Code Coverage and then selecting All Tests or Selected Tests (this is your selection in the Test Explorer window). You can open the code coverage results and double click any of the lines - which will open the code and highlight the coverage. To enable code coverage in the automated build, edit your build definition. Click on the Execute Tests task, and find the Run Settings File parameter. If you have a generic run settings file, you can place it in the C:\DynamicsSDK folder on the build VM, and point to it here (full path). Optionally, if you have a settings file specific for certain packages or build definitions, you can be more flexible here. For example, if the run settings file is in source control in the Metadata folder, you can point this argument to "$(Build.SourcesDirectory)\Metadata\MySettings.runsettings". The biggest issue with this is the extra IL code that our compiler generates, namely the pre- and post-handler code that is generated. This is placed inside any method, and is thus evaluated by code coverage even though your X++ source doesn't contain this code. As such most methods will never get 100% coverage. If a method has the [Hookable(false)] attribute (which makes the X++ compiler not add the extra IL code), or if the method actually has pre/post handlers, the coverage will be fine. Note that Chain-of-Command logic that the compiler generates is nicely filtered out.

Test Attributes and Filtering

Joris dG — Tue, 31 Oct 2017 14:26:15 GMT

By popular demand, Platform Update 12 contains improvements on SysTest class and method attributes in X++, and how they behave in the Visual Studio test window as well as the VS Test Console, which is the tool used in the automated build process. Our goal was to improve and support the major test attributes in our SysTest framework adapter to be on par with the MSTest framework adapter. This includes attributes like Category, Owner, Priority and Test Property. TestCategory The Category attribute (SysTestCategoryAttribute) was already available in previous releases using the SysTestCategory attribute. With the new platform update however, you are now able to specify multiple categories on both the class level and the individual method level. Additionally, the TestCategory is now enabled for filtering in the VS Test Console, which means you can create build definitions with test filters on specific categories. You can use the "TestFilter" variable in the build definition for this, for example set the variable to "TestCategory=Nightly" to only run tests with a category "Nightly". Priority The Priority attribute (SysTestPriorityAttribute) has been added, requiring an integer value. A priority can only be specified once but is supported on both class and method level, with method level taking precedence over class level. It is also exposed as a test filter so you can use the "TestFilter" variable in the build definition for this, for example set the variable to "Priority=1" to only run tests with a priority of 1. Owner The owner attribute (SysTestOwnerAttribute) has been added as well. This attribute was technically already supported for filtering in the Test toolbox window but the attribute itself was missing in X++. Like priority, an owner can only be specified once and is supported on both class and method level, with the method level taking precedence. Owner is not available as a test filter for the console, which is in line with the MSTest adapter for VS Test Console. Owner will show up in the Test toolbox window in Visual Studio, however. Test Property The test property attribute (SysTestPropertyAttribute) has existed in previous releases of the platform, but wasn't fully functional. Unfortunately the SysTestPropertyAttribute exists in the Application Foundation package as opposed to the other attributes which exist in Test Essentials. Due to our commitment to backwards compatibility of the platform we can't currently move this attribute to its expected location, so you will need to add a reference to the Application Foundation package to use it. Test Property specifies a property and a value (two strings) and can now be used in the Test toolbox window in Visual Studio. Test properties can be specified multiple times, and can exist on both class and method level. Test property is not available for test filtering in the VS Test Console, in line with the MSTest adapter. For advanced filtering syntax that can be used with the VS Test Console, see Running selective unit tests on Microsoft Docs for .NET and review the filtering examples for the MSTest framework. Note that for test filtering purposes we have also always allowed you to filter on FullyQualifiedName and Name, and those features continue to exist.

Pointing Build Definitions to Specific VMs (agents)

Joris dG — Fri, 20 Oct 2017 13:20:42 GMT

We've recently collaborated with some customers who are upgrading from previous releases of Dynamics 365 to the recent July 2017 application. These customers typically have to support their existing live environment on the older application, but also produce builds on the newer application (with newer platform). Currently the build agent is not aware of the application version available on the VM. As a result, Visual Studio Team Services (VSTS) will seemingly randomly pick one or the other VM (agent) to run the build on. Obviously this presents a challenge if VSTS compiles your code on the wrong VM - so the wrong version of application and platform. We are reviewing what would be the best way to support version selection, but in the mean time there is an easy way to tie a build definition to a specific VM. First, in LCS go to your build environment and on the environment details page, find the VM Name of the build machine. In this particular example below, the VM Name is "DevStuffBld-1". Next, go to VSTS and find the build definition you wish to change. Note that if you have more than one version you're building for, you will want more than one build definition - and point each to its respective VM. To make sure a build definition points to a specific VM, edit the build definition and find the Options tab. Under Options you will find a section of parameters called Demands. The demands are effectively either specific values setup on the agent setup in VSTS (you can do this in the Agent Queue settings), and the agent also picks up all environment variables on the VM it runs on. You will notice that all build definitions already check for a variable called DynamicsSDK to be present to ensure the build definition runs only on agents where we have set this "flag" if you will. Since each VM already has an environment variable called COMPUTERNAME, we can add a demand for computername to equal the name of our build VM. So for the example of the build VM from above, we can edit our build definition to add the following demand by clicking +Add: Save your build definition and from now on your build will always run on the right VM/agent.

How to setup build agent and create a build definition manually

Sagar Bakliwal — Mon, 24 Oct 2016 15:23:13 GMT

If you run into any issue with your build machine deployment and would like to manually retry the build agent setup and build definition creation, then follow these steps (These steps are for a build environment machine deployed from LCS. Developer machine will not have the folder and files mentioned below) Setup build agent

Open powershell command prompt as Administrator
Go to C:\DynamicsSDK and run the following script -
- C:\DynamicsSDK> .\SetupBuildAgent.ps1 -VSO_ProjectCollection "https://yourproject.visualstudio.com/DefaultCollection" -AosWebsiteName "" -VSOAccessToken "" -AgentName "< Optional - Some recognizable agent name if you want>" -AgentPoolName "" -Force
- -Force switch is required if there was previous attempt to setup the build agent on that machine. It will ensure cleanup of the old agent and configuring it again.
Once the script run completes you should be able to see the new agent added to your agent pool.

Create new build definition

Open powershell command prompt as Administrator
Go to C:\DynamicsSDK and run the following script -
- C:\DynamicsSDK> .\BuildEnvironmentReadiness.ps1 -VSO_ProjectCollection "https://yourproject.visualstudio.com/DefaultCollection" -ProjectName "" -VSOAccessToken "" -AosWebsiteName "" -AgentPoolName "" -Branch "" -BuildDefinitionName "" -Force
- Note - The -Force switch is useful if you want to overwrite the build definition and AXModulesBuild.proj file which is already present under your project.
Once the script run completes you should be able to see the new build definition added to your project.

Note - You can find out your Local AX Website Name by opening up IIS manager. Here it is "AOSService"

Automated testing guidance for AX 7

Sagar Bakliwal — Fri, 12 Aug 2016 12:08:07 GMT

Couple of links that will be helpful while thinking about testing in general

X++ test attributes

Attribute Name	Usage
SysTestMethod	A method decorated with this attribute in a Test Class is considered as Test method (you can also just start the method name with 'test' and it will be treated as a test method.
SysTestInactiveTest	Deactivates the Test From Execution List
SysTestCaseConfigurationKeyConstraint	Class level and Method Level. The test can only run if the specified configuration key is enabled. It reports as inactive otherwise. example: [SysTestCaseConfigurationKeyConstraintAttribute(configurationkeystr(PMF)] //test will only run if the PMF configuration key is turned on
SysTestCaseConfigurationKeyDependency	Class level only. Requests the framework to activate/deactivate a configuration key temporarily for the purpose of the test. example: [SysTestCaseConfigurationKeyDependencyAttribute(configurationkeystr(PMF))] //test will always run. Turns PMF on during the test execution (if was off to begin with) [SysTestCaseConfigurationKeyDependencyAttribute(configurationkeystr(PMF), false)] //test will always run. Turns PMF off during the test execution (if was on to begin with)
SysTestCaseCountryRegionDependencyAttribute	Class level only. Requests the framework to run the tests in the provided country/region context. Example: [SysTestCaseCountryRegionDependencyAttribute('US')] This will enable US Country/Region features like tables, forms, etc. during test execution. It will also make country/region specific code execute. Please note that this feature works by injecting the country/region ISO code into the global cache. If for some reason the cache is cleared during test execution the effect dissapears.
SysTestCaseDependsOnReportAttribute	Method level only. Deploys the Report Design or all the designs within the Report. SysTestCaseDependsOnReportAttribute("BIR_RptNoParameter") // Only specify the report name without the design name in order to deploy all designs within a report. SysTestCaseDependsOnReportAttribute("BIR_SimpleReport.AutoDesign1") // Specifiy the report + design name to deploy a specific report design.
SysTestGranularity Parameters:	Marks the testclass or test method with this attribute Unit, Component, Integration, or BusinessCycle
SysTestFixture Parameters: [classstr(SysTestSuiteClass)]	The suite has the knowledge of what test classes or test methods but it’s not the other way. Where test classes or test methods know which suite they belong to. In Rainier, using the SysTestFixture Attribute, [SysTestFixture(classstr(WorkflowRuntimeTestSuite))] class SysWorkflowTest extends SysTestCase { public void testcancel() {} } public class WorkflowRuntimeTestSuite extends SysTestSuite { public void setUp() { } public void tearDown() { } } Through the SysTestFixture Attribute, we could enable test classes/methods to have the knowledge of which test suite they belong to. While executing the tests from visual studio tools (IDE and vstest.console.exe) SysTestFixture metadata is used to group the testmethods and execute them together, which would in turn run the suite-level setup() and teardown() once.
SysTestCaseNumSeqTypeDependency	Flags that the specific test class depends on a number sequence module. The system will ensure that the number sequence module and the specific data type is created prior to the test execution. Only the specified data type is setup for the execution of the test. Note: try to use SysTestCaseAutomaticNumberSequencesAttribute first before using this attribute. With this attribute the test case should upgrade code like this: SysTestCreateData_Basic::createNumberSequenceETId(NumberSeqModule::Invent, extendedtypenum(InventDimId)); To an attribute like this: [SysTestCaseNumSeqTypeDependencyAttribute (extendedTypeStr(InventDimId), classstr(NumberSeqModuleInventory))] For tests that depend on a small set of number sequences, this is the preferred way of setting up number sequences when the test case is not compatible with SysTestCaseAutomaticNumberSequencesAttribute. The number sequences created with this attribute are based on the default settings of the data types. Any customization to the setup, format or parameters of the number sequence (i.e. "Continuous", "Manual", etc) needs to be applied during the SetupTestCase. Use of this attribute gives a very big performance gain compared to traditional methods such as SysTestCreateData_Basic::createNumberSequenceETId(NumberSeqModule::Invent, extendedtypenum(InventDimId));
SysTestCaseNumSeqModuleDependency	Flags that the specific test class depends on all number sequences within a given module. The system will ensure that the number sequence module and all its data types are created prior to the test execution. Note: try to use SysTestCaseAutomaticNumberSequencesAttribute first before using this attribute. With this attribute the test case should upgrade code like this: SysUnitTestData_Proj::setupNumberSequences(NumberSeqModule::Sales); To an attribute like this: [SysTestCaseNumSeqModuleDependency(classstr(NumberSeqModuleSales))] For tests that depend on a many number sequences of a given module, this is the preferred way of setting up number sequences when the test case is not compatible with SysTestCaseAutomaticNumberSequencesAttribute. The number sequences created with this attribute are based on the default settings of the data types. Any customization to the setup, format or parameters of the number sequence (i.e. "Continuous", "Manual", etc) needs to be applied during the SetupTestCase. Use of this attribute gives a very big performance gain compared to traditional methods such as SysUnitTestData_Proj::setupNumberSequences(NumberSeqModule::Sales);
SysTestCaseAutomaticNumberSequencesAttribute	Flags that the specific test class may use number sequences and the system should create, at runtime and upon request, the right setup. With this attribute the test case should be removed of code similar to: SysUnitTestData_Proj::setupNumberSequences(NumberSeqModule::Sales); Or SysTestCreateData_Basic::createNumberSequenceETId(NumberSeqModule::Invent, extendedtypenum(InventDimId)); The use of this attribute actually changes the runtime behavior of number sequences to setup the data types and modules as they are requested. There is no performance cost of this attribute against the SysTestCaseNumberSeqModuleDependency or SysTestCaseNumberSeqTypeDependency and this mechanism ensures that, at runtime, only the needed types are created and no excessive setup is performed. This attribute may not produce the right results when the test case executes one of the following type of validation: · Tests that validate the number sequence framework itself. · Tests that expect non-existent number sequences. · A small number of tests validate number sequence reservation ("continuous") behavior may fail. The number sequences created with this attribute are based on the default settings of the data types. Any customization to the setup, format or parameters of the number sequence (i.e. "Continuous", "Manual", etc) needs to be applied during the SetupTestCase. Use of this attribute gives a very big performance gain compared to traditional methods such as SysUnitTestData_Proj::setupNumberSequences(NumberSeqModule::Sales); This attribute may produce a negative performance effect when you are replacing a very well behaved class that does one-time setup of one number sequence code. In this case, try using SysTestCaseNumSeqTypeDependencyAttribute (see above).
SysTestCaseDatasetDependency	Class level attribute. DOES NOT work when applied at method level INHERITED (but not overridable) Flags that the specified test class needs to run on a given Dataset, starting on the specified company. Usage: SysTestCaseDatasetDependencyAttribute( str _datasetName, selectableDataArea _dataAreaId = 'DAT' ) A dataset is a logical name of the Test data collection. It is not a partition where the data got imported to. The system will switch execution to the partition where the data is imported to and launch the execution on the company. If the dataset requested is not present in the system the test case will fail.
SysTestSecurityAttribute	Class level attribute. DOES NOT work when applied at method level NOT INHERITED By default all test run with System administrator rights. In this example 2 personas are defined on a test class · each is given a different security role (the roles are defined in a list of assigned roles). · SystemUser role is automatically added by the framework · Note the TestEssentialsRole was explicitly added by the owner of the test since SystemUser does not have rights to all test framework endpoints. Task 1737753 will look into adding that role implicitly. · The old notion of a “user” is now called a “persona”, this is because we are not actually switching users midstream, but instead, are reconfiguring the user’s permissions · No kernel hooks were added for any of this, it only uses the development hook which was already available in 6.x.—‘SysAdminMode’ · One of them sets default = true which means that the role becomes the default for the test methods (the setup() methods are all executed without a user context) · Using statements are not required, but are a preferred way of scoping the user’s context · The code controlling the behavior is completely encapsulated in the SysTestSecurityContext class. · MethodEnter/Exit and TestExecutable Enter/Exit control when settings are automatically changed back to admin and the default contexts · TestEssentialsRole is required for execution of form adaptor based tests Sample: for complete reference see the SysTestSecurityContextTest class #define.PersonaSecRole('u1') #define.PersonaSecUserRole('u2') [SysTestTargetAttribute(classstr(SysTestSecurityContext), UtilElementType::Class), SysTestSecurity(#PersonaSecRole, [ 'SysTestSecurityContextTestRoleSecRole', 'TestEssentialsRole' ], true), SysTestSecurity(#PersonaSecUserRole, [ 'SysTestSecurityContextTestRoleSecUsrRole', 'TestEssentialsRole' ], false)] class SysTestSecurityContextTest extends SysTestCase -------NOTE--------------- This attribute does apply the role correctly, but the priviliges assigned to any duty connected to this role will drive the security context. What it means is that if your Test is using a security role say HcmHumanResourceManager, which has one of the duties as HcmWorkforceProcessInquire which ultimately has the privilige HcmADARequirementView. This privilige has the entry point set to HcmADARequirement with a read access to display menuitem HcmADARequirement. So if you are using this SysTestSecurityAttribute with the HcmHumanResourceManager role, you will get view access if you do use form interaction (form adaptor based tests). But if you decide to directly interact with the table HcmADARequirement, you will end up getting a Delete access by default. If you don't want to test using the form adaptors but directly interact with the table (for eg) and still want the security context applied you will have to manually push the security context in your test code. SecurityContext context = SecurityContext::constructFromEntryPoint(SecurableType::MenuItemDisplay,menuItemDisplayStr(HcmADARequirement),''); context.push(); *//Your code to ineract with the table goes here* SecurityContext::pop();
SysTestTransaction	Class level attribute. DOES NOT work when applied at method level NOT INHERITED Defines what is the test data rollback mechanism once the test class finishes. Default - [SysTestTransaction(TestTransactionMode::AutoRollback)] Uses the savepoint mechanism. Data is never committed to the database and is only accessible within the transaction scope. This was introduced with AX7. [SysTestTransaction(TestTransactionMode::LegacyRollback)] This is the same way as 6.0 and it saves the data in the database but tracks what records have been inserted and reverts them once the test execution is over. [SysTestTransaction(TestTransactionMode::None)] This will commit the data to the database and won't cleanup after the execution completes.

How to generate form adaptors for new forms-

Pre-requisite -> You have new module or model created for production code and also one for test code. Also at least one form is present in the model

Open the descriptor file for the test module from the packages eg - I:\AOSService\PackagesLocalDirectory\NewTestModel\Descriptor\NewTestModel.xml and add this line

NewFormModel This will mark this test module to hold the form adaptors for the NewFormModel model

Open the properties window for the NewFormModel project and set the 'Generate form adaptors' property to true

Now build the NewFormModel project and it will generate a new class called SomeSampleFormFormAdaptor under the NewTestModel. Refresh the application explorer and you should see the file.

How to record validation steps in task recording- You can add validation steps to your task recording that will be converted to assert statements when you import the recording back into Visual Studio as a test. There are two type of validations you can record

Validate the value you see directly - Right click on the field you want to validate -> Task recorder -> Validate -> Current Value. This will always validate the value Contoso Europe in the example below and even the test generated from the recording will be validating this value.

Validate the value by matching it with some other field - This is useful when you are actually less worried about what the value is, but in fact you want to make sure that the value matches some field that you copied earlier. From the example above, instead of clicking on Validate, you can click on Copy. Then on the Customer details form you can right click on the Name -> Task recorder -> Validate -> (Now you see two options). Instead of choosing Current value, you can choose to match the Name to the CustTable_Name field from the List page that you had copied. This is very use full if you want to track the progress of any field value.

Known Limitations These are not necessarily limitations, but the current design.

Tests can run in a clean partition if no dataset is provided or in the company belonging to the dataset that is loaded. You cannot combine tests that target different datasets because we don't have the capability to switch dataset on the fly. It will be costly to switch as well since it takes a long time to drop and restore the database. If you want to have tests that target different sets of data, then prepare your database with different partition and that way the partition can be switched easily to execute the tests.
Data created during a test run gets cleaned up after the test finishes. Currently we don't support running the test in any particular order. So you cannot assume that the data from test1 can be used by test2.

VSTS Integration: Errors and Resolutions

ajayjha — Fri, 08 Jul 2016 16:51:56 GMT

This article provides a comprehensive list of error message and resolution that the user or IT administrator can run into on Dynamics Lifecycle Services during deployment of Build agent. Resolution in most cases is to fix configuration issues in VSTS. Note - All of the errors related to permissions can be avoided if the personal access token associated with the Dynamics Lifecycle Services belongs to either the VSTS account owner or is the user is part of the Team foundation administrator group.

Issue - LCS deployment failing because the new build agent starts processing build request even though the deployment process hasn't finished completely.

Error Message - Post deployment error similar to "Timed out waiting for event: ProvisionWorkItem"

Resolution

Before you ask for a new deployment from LCS, make sure you don't have pending builds queued. The agent pool you are trying to add the agent under should not have any active requests for build. This is so that the new build agent being deployed doesn't start processing builds while in the midst of completing the LCS deployment process causing the deployment to fail. You can follow these steps to help you avoid this issue. Go to the agent queue page and see if there are any builds queued against your existing dead or disabled agents. Eg. Here you can see there are 2 builds queued (they have not started executing yet) since there is no agent available to process the request. You can either click on the Name link of the build (2016.6.13.1 and 2016.6.13.2 in this case) and then cancel the request from that page. Or you can use a different agent pool to create the new agent so no existing request can be processed on that machine. But then you would still have to go an delete those queued build requests if you would like the new agent to start processing them. Also if you have existing build definitions make sure to disable the auto scheduled triggers so that a new build request doesn't get queued while in the process of deployment.

Issue - VSTS project could not be found

Resolution

There are 3 potential reasons for this error and you need to verify all of them.

Either the VSTS project that was connected to LCS was deleted.
Or the user does not have access to the project any more.
Or the token that was used in LCS has expired or has been revoked.

Issue - Invalid access token

Resolution

The project does exist in VSTS but the token that was used has either expired or it has limited scope. Make sure that the token you use is created with 'All scopes'. Note that selecting 'Selected scopes' and then selecting all the options is not similar to selecting 'All scopes' in VSTS. You have to choose 'All scopes'

Issue - No more private agent slots

Resolution

Need to have at least one free agent slot available. Free VSTS account comes with one private agent capacity. If you had already deployed a dev/test environment from LCS that deploys a build agent then you have already used up the free agent capacity.

If you truly want another build agent then you can pay for more capacity. Instructions can be found here - https://www.visualstudio.com/en-us/docs/setup-admin/team-services/get-more-build-or-load-testing-vs
On the other hand if you just care about 1 build agent but still want to deploy another dev/test environment then after you delete your previous environment you should go to your VSTS agent pool and either delete the old agent by clicking on the x. Or you can simply disable the agent by unselecting the checkbox.

Issue - Agent pool does not exist

Resolution

The agent pool name provided in LCS should be a valid agent pool that already exists in your VSTS account. If you don't provide any value then we use 'Default' agent pool. This agent pool will be used to connect your build agent.

Issue - User has only stakeholder access level

Resolution

In order to talk to VSTS rest API we need the user that is associated with LCS to at least have User level access (Anything more than Stakeholder). Go to your VSTS user management page and change the access level of the user that is associated with LCS or change the user in LCS to someone that has higher access level.

Issue - User does not have administrator privilege to the agent pool

Resolution

In order to be able to attach a build agent to a given agent pool, the user needs to have admin access to the agent pool. There are multiple ways to solve this problem

Use the token for the VSTS account owner. They have permissions to everything in VSTS.
Add the current user to Team foundation administrator group or use a token for another user that belongs to that group. No more settings are required after this and you get admin permission.
If instead you would want to use a token with restricted access, then you need to make sure that the user has at least the following permissions -

User access level should not be Stakeholder as mentioned above.
User should have access to the VSTS project associated with LCS
User should have admin access to agent pool.

User could be added directly to the Admin group User could be added to the Agent pool administrators group

Issue - VSTS project that is connected with LCS only support GIT version control

Resolution

Currently we only support TFVC for version control and not GIT. To get around this error -

Either create a new project and select Team Foundation Version Control for the version control option

Or add TFVC as another supported version control to the existing GIT project. Go to your project -> Code section and click on the GIT repository drop down and click on New repository On the Create a new repository page, select the Type as TFVC and hit create This will create a new TFVC version control for your code.

Issue - Agent name is not set with correct format

Resolution

Make sure the Agent name that you have used in LCS follows the suggested pattern.

Issue - Branch name is not set with correct format

Resolution

Make sure the Branch name that you have used in LCS follows the suggested pattern. Only provide the name of the branch and not a path in LCS. We use Main as the default branch name. The branch that gets created in VSTS will be of format /$/Trunk/

Issue - No agent queue exists for agent pool

Resolution

Normally when you create an agent pool it provides an option to create the agent queue in all projects automatically. But if you haven't selected that option or you have manually deleted the agent queues then you will have to recreate the agent queue. Go to the settings page of your project and hit the New queue button On the next window select the option of Using an existing pool and select the pool that you want to deploy against. Name of the agent pool will be appear in the error message.

Issue - User does not have Edit build definition permission

Resolution

The user needs Edit build definition permission to be able to publish a new build definition to the configured project. You can update the settings looking up the security related to build definitions On clicking the Security option you will see the following permissions page. Either you can add the user to one of the VSTS groups that has edit build definition or add the user directly to this project and change the Edit build definition permission to Allow. While you are at it also update the Delete build definition permission to Allow as well. When we perform this check on LCS we upload a temporary build definition to your account to validate the permissions and once it is successful we try to delete the definition. We don't throw any errors if the deletion failed as that is not a mandatory permission for the deployment to be successful. If you don’t give Delete build definition permission you might see a build definition lying around with a name similar to "Delete - AX7 Test Build " which you can manually delete later. Note - make sure to hit the Save changes button to save the permissions.

Issue - User does not have Use permission for agent queue.

Resolution

User Should have a minimum of User permission to the queue that is associated with the agent pool (queue name will show in the error message). Go to the settings page of your project and look up the Agent queues tab You can either add the user to one of the groups that has the Administrator role or add the user directly at this level by hitting the add button. And then selecting either User or Administrator role. Don't select the Reader role.

Configuring VSTS with Dynamics Lifecycle Services for Continuous Integration

ajayjha — Mon, 02 May 2016 05:40:32 GMT

Dynamics lifecycle services provides you with the capability to provision custom build agents as part of you LCS project. While developing an AX solution; using the build environment gears you up to follow the best practices for continuous integration of Dynamics AX application. Continuous Integration allows you to

Follow the optimal branching and source/version control strategy
Utilize automated build orchestration using VSTS
Utilize automated deployment of your custom AX solution on the build environment
Create self-testing build with automated tests authored for AX application
Reports and notifications on the status of your builds

In order to get started with continuous integration and delivery of AX solutions built on Dynamics AX platform, you need to create a VSTS account and link it with Dynamics lifecycle services portal.

Sign up for Team Services - It is required to use the same Azure active directory that you used to create the Dynamics lifecycle project. If you are unfamiliar with Azure Active directory, please read through and understand the security and access control model for team services with Azure Active directory as an organization.
Create a personal access token - Clients like Visual Studio natively support Microsoft account and Azure AD authentication with team services, so you can directly use these authentication mechanisms from your AX developer environments hosted either on Azure or on premise. As part of the cloud build environment provisioning through Dynamics LCS, you need to create a personal access token and use that in LCS project settings. Please refer to this MSDN article on creating personal access token.
Connect your LCS project with VS Team Services – Personal access token is associated with a user profile and is your identity. It should have the right permissions to create a custom build agent on the agent pool of your team services account. Agent pools are used to organize and define permission boundaries around your agents. Pools are scoped to your Team Foundation Server application tier or Visual Studio Team Services (Team Services) account. If you are using the personal access token of the Team Services account owner in Dynamics LCS, you already have all the required access to the agent pool and queue. If you are using a personal access token of a user who is not the account owner, make sure the user has been added as an agent pool administrator. You can administer your pool from this URL - Team Services: https://{your_account}.visualstudio.com/_admin/_AgentPool; Members of this group can register new agents in the pool and add additional users as administrators or service accounts.

Once done with the above three steps, you are now ready to deploy a build environment using Dynamics Lifecycle Services. If you are interested in learning more about what happens during provisioning of your build environment on Azure, please refer this blog article.

Dynamics AX Application Test Strategy

ajayjha — Mon, 02 May 2016 03:15:00 GMT

Dynamics AX provides a fully features testing framework that works in a pattern similar to any xUnit test harness. This harness allows developers to author unit, component and scenario level tests. Additionally, since the development environment is integrated with Visual Studio, there are many productivity enhancing developer scenarios like better debugging, diagnostics and code analysis available with the IDE. A version of the testing quadrants by Alan Page describes scope and activities of testing quite well. This has been adapted from Brain Marick’s “Agile Quadrants” to describe the scope of testing. [1] [2] Task recorder based record and playback tests falls under Q4. These tests are typically scenario based and are customer facing. Unit and component tests fall under Q1. For Q4, performance SDK offers load and performance testing capabilities. Dynamics AX Test Strategy A good test strategy answers three basic questions [4]

Why bother? Testing and test automation takes effort and time. In order to ensure proper investment, testing activities should be driven to address specific risks.
Who Cares? Include activities in your tests that serves somebody’s interest. For ex., customers who care about a specific feature or scenario.
How much? It is impossible to test all possible combinations and scenarios. There should be clear definition of how much effort will be put in testing and test automation.

What is a good test case? There are many articles about quality of a test case. In a nutshell a good test case is [3]

Relevant: Uniquely tests what is intended
Effective: Proves or disproves the software. Finds bugs! No false positives or negatives.
Maintainable: Easy transition of tests for someone else to setup, run and interpret results
Efficient: Returns definitive results quickly with efficient use of resources.
Manageable: Test deployment, configuration, organization, test business metadata (owner, priority, feature association, etc.)
Portable: Runs anywhere with appropriate adaption to current environment
Reliable: Software reliability + results repeatability. Same input and environment=same test results.
Diagnosable: Low Mean Time to Root Cause (MTTRC) and accurately identifies product, test and infrastructure failures separately, starting with a good name.

Resources For some excellent advice on testing and test strategy please refer to blog Achieving balance in testing software References [1] Agile Testing Directions; https://www.exampler.com/old-blog/2003/08/21/#agile-testing-project-1 [2] Riffing on the Quadrants; https://angryweasel.com/blog/riffing-on-the-quadrants/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ToothOfTheWeasel+%28Tooth+of+the+Weasel%29 [3] Improving Test Quality; David Catlett, Mind Shift, 2011 Engineering Forum [4] Kaner, C., Bach, J., & Pettichord, B. (2001). Lessons learned in software testing (1 ed.). New York, NY, USA: John Wiley & Sons.

AX Source Control and Branching Guidelines

ajayjha — Mon, 02 May 2016 02:41:55 GMT

The source control system supported by AX Developer ALM system is VSTS based TFVC (Team Foundation Version Control). If you are new to TFVC, please check - Develop and share your code in TFVC using Visual Studio TFVC is a centralized version control system that storing source code in shared repositories, isolate parallel development efforts, integrate code changes, and to recover previous file versions. Basic TFVC concepts

Branch: is an isolated copy of item metadata and version control history.
Changeset: is a logical container for changes of a single check in.
Label: provides mutable groupings of specific version of a set of source files.
Workspace: is a local copy of your codebase. You can create multiple workspaces and switch among them to work on different branches or copies of the codebase. A Workspace maps Server folders to Local folders. This includes:
- A list of all the files in your workspace
- The version of each file
- A list of the pending changes
- Active and cloaked items

Source Code Structure in TFVC for your AX application In order to get started with TFVC version control for your AX project, you need to check in AX Modules you are developing under the Metadata folder. While provisioning the build environment if there is no custom branch name specified, a folder called Main is created for you while creating the build definition. This is structure to follow to check in your code for X++ projects. You can consume .NET projects in your AX application and the default build definition created supports compiling and adding your .NET assemblies to AX Modules. In order to build and source control your C# projects please check them into TFVC following this structure. Common Branching Strategies for AX Development Branching enables parallel development by providing each development activity a self-contained snapshot of needed sources, external dependencies and build orchestration automation. Having more branches increases complexity and merge costs. Nevertheless, there are several scenarios where you will need to consider multiple branches to maintain a required development velocity. These are the branching strategies we recommend

No Branching: Do not branch unless you really need to. This is the simplest strategy to start with for your AX development project and works great for small teams developing a single version of the application at a time. Branching introduces cost of maintenance and shelveset is a great feature of TFVC to save and share changes in TFVC without committing them to the branch. For more information, please refer - Suspend your work and manage your shelvesets
Branch per release: Branch contains code for specific release version. This enables concurrent release management and isolation. It is recommended to branch everything you require to develop in parallel, typically this may mean branching the entire parent. Branch from a parent with the latest changes (usually MAIN or another DEV branch you specified in LCS)

For steps to accomplish this please refer – Branch folder and files We are in the process of evaluating distributed version control system - Git for AX development. Stay tuned for updates in this blog.