Automated Testing in Dynamics 365 For Operations. Devin Steinke Solution Architect, PCL

Size: px

Start display at page:

Download "Automated Testing in Dynamics 365 For Operations. Devin Steinke Solution Architect, PCL"

Osborne Tucker
5 years ago
Views:

1 Automated Testing in Dynamics 365 For Operations Devin Steinke Solution Architect, PCL

2 Testing Principals

Usability Testing UAT Unit Tests Component Tests Performance &

3 Testing Quadrants Automated & Manual Manual Functional Testing Story Tests Business Cycle or Integration Exploratory Testing Usability Testing UAT Unit Tests Component Tests Performance & Load Testing Security Testing Automated Tools Source: Brian Marick

4 Test Pyramid Business Cycle Or System $ Integration Component Unit

5 Automated test best practices Reliable Tests produce the same results run after run Maintainable Minimal or no effort to update from version to version Fast Supports developer testing and gated check-in Simple Tests have a clear intent and are easy to understand Precise Failures are localized, easy to pinpoint exactly why the test failed

6 Unit test best practices Focus on what you re testing and target that Don t overload the purpose of the test Only test one thing in each test method Test both positive and negative outcomes, and important edge cases You may end up with many unit tests for a single method Be explicit on granularity of the test using the attribute [SysTestGranularityAttribute::Unit)] Write valuable unit tests - don t test un-customized framework elements, focus on brittle areas of code Consider writing the unit test before you code the method or bug fix - this will ensure you have a better understanding about what you are developing

7 Why automated tests? Safety net for new developers Reduce the risk of cracking open complicated modules Reduce the burden on manual (human) regression testing Significantly increase product quality Potential to increase code quality for free via gated check-ins Little or no lag time between check-in and test break

8 Test Pyramid in D365FO Business Cycle Task Recorder Integration Task Recorder / SysTest Component Unit Task Recorder / SysTest SysTest Business Cycle Or System Integration Component Unit

9 Continuous Integration Demo

10 Test analytics

11 Test run summary

12 Data Rollback

13 Data Rollback Baked into SysTest framework This is NOT x++ transactions Uses SQL SavePoints Transactions are nested Framework > TestSuite > TestClass > TestMethod Eliminates need for developer to manage data rollback, increase test reliability Coding errors or exceptions no longer leave data in an unreliable state

14 Test Framework SavePoint Manager Suite Test Class A Test Class B Data Rollback Create SavePoint 1 (Suite) Create SavePoint 2 (Class) Suite setup() SetupTestCase() setup() test1() Rollback to SavePoint 2 (Class) teardown() setup() test2() Rollback to SavePoint 2 (Class) teardown() Rollback to SavePoint 1 (Suite) Create SavePoint 3 (Class) SetupTestCase() setup() test1() Rollback to SavePoint 3 (Class) teardown() setup() test2() Rollback to SavePoint 3 (Class) teardown() Rollback to SavePoint 1 (Suite) Rollback to Initial Suite teardown()

15 Anatomy of a Unit Test

16 Anatomy of a Unit Test [SysTestTarget(classStr(PCLPCFCostCodeManager), UtilElementType::Class), SysTestFixture(classStr(PCLPCFCostCodeTestSuite))] class PCLPCFCostCodeManagerTests extends SysTestCase { [SysTestMethodAttribute, SysTestGranularityAttribute(SysTestGranularity::Unit)] public void test_component_level_3_cost_code_cannot_be_deleted() { //Arrange PCLPCFProjCostHierarchyTreeNode costcode; costcode.costcode = PCLPCFCostCodeTestSuite::TestCostCodeNumber; costcode.costlevel = PCLPCFCostLevel::Component; // skip insert validation logic, irrelevant to the test costcode.doinsert(); //Act boolean result = PCLPCFCostCodeManager::validateDelete(costCode, false); } } //Assert this.assertfalse(result); this.assertexpectedinfologmessage('system level cost headers cannot be deleted');

17 Anatomy of a Unit Test Class attributes [SysTestTarget(classStr(PCLPCFCostCodeManager), UtilElementType::Class), SysTestFixture(classStr(PCLPCFCostCodeTestSuite))] The [SysTestTarget] attribute must be present references the class / form / table the test is targeting If testing a form, formstr() method would be used, and UtilElementType::Form is supplied The [SysTestFixture] attribute denotes the text fixture used Generally test fixtures are shared among many like test cases

18 Anatomy of a Unit Test Class definition class PCLPCFCostCodeManagerTests extends SysTestCase Test case classes are named after the element they are testing Test class names are always post fixed with Tests, and extend the SysTestCase class

19 Anatomy of a Unit Test Method attributes [SysTestMethodAttribute, SysTestGranularityAttribute(SysTestGranularity::Unit)] [SysTestMethodAttribute] tells the framework this method is a test Test case classes can have other helper methods [SysTestGranularityAttribute] is a grouping mechanism only Strictly speaking, is it optional, but in practice it should not be

20 Anatomy of a Unit Test Method signature public void test_component_level_3_cost_code_cannot_be_deleted() The method signature should be a human readable string of text that concisely explains the intent of the test Spaces (if used) are represented by the underscore character Limited to 81 characters in length (X++ limitation) SysTest methods must follow these strict rules: Method signature MUST start with test Must return void Must be public Cannot have parameters

21 Anatomy of a Unit Test Arrange block //Arrange PCLPCFProjCostHierarchyTreeNode costcode; costcode.costcode = PCLPCFCostCodeTestSuite::TestCostCodeNumber; costcode.costlevel = PCLPCFCostLevel::Component; // skip insert validation logic, irrelevant to the test costcode.doinsert(); D365FO is extremely data driven, so this step generally involves inserting data into the database Initialize the absolute minimum data required to execute your test Use doinsert() and doupdate() to avoid introducing table logic (keep it simple!) Some tests may not even need the record in the database!

22 Anatomy of a Unit Test Act block //Act boolean result = PCLPCFCostCodeManager::validateDelete(costCode, false); Execute the focus of the test and record the result(s) Often this will be a single line of code If more, likely breaking one of the best practices (keep it simple, precise)

23 Anatomy of a Unit Test Assert block //Assert this.assertfalse(result); this.assertexpectedinfologmessage('system level cost headers cannot be deleted'); Validate the result(s) of the Act block Check expected (or not expected) messages in the Infolog Remember that negative tests are just as important as positive tests The this keyword is used to access SysTest helper methods

24 SysTest Demo

25 SysTest class

26 Task Recorder Demo

27 Task recorder

28 Import task recording into Visual Studio

29 SysTest From Task Recording

Additional Resources: Devin Steinke s Blog http://coffeestain-it.blogspot.com/ Dave Froslie Microsoft Principal Software Architect https://blogs.msdn.microsoft.

30 Additional Resources: Devin Steinke s Blog Dave Froslie Microsoft Principal Software Architect D365FO Wiki Testing support in Visual Studio More questions? Please contact Devin at: dsteinke@pcl.com

31 THANK YOU FOR ATTENDING!

Software Testing Workshop 2014 Introduction

Software Testing Workshop 2014 Introduction May 3 rd 2014. FAST, Islamabad. About Us Majd Uddin 15+ years of experience with a decade in software testing Promoting software quality: M.Sc. (CS) from PUCIT,