Workshop 2 - Writing your own automated tests

LUC VAN VUGT, MVP – FLUXXUS.NL

Introduction - Me

31 years happy together

6 years
56 years

2 year no sports
24 years, 3 times father

19 years Dynamics NAV 8 years Dutch Dynamics Community

8 times Microsoft MVP

Luc van Vugt 6 years The Learning Network

enchanté
6 years
Introduction – And You

Name
Company

NAV
Testing

Expectations
Introduction - And You

Do you know the Testability

Framework that is build in NAV?
i.e. technical features like test
codeunits, ASSERTERROR, etc.
Introduction - And You

Did you already build and execute

test yourself?
Preparations
Azure VM
Preparations – Azure VM / MSSSMS
https://docs.microsoft.com/en-
us/sql/ssms/download-sql-server-
management-studio-ssms?view=sql-
server-2017

http://lvvws#.northeurope.cloudapp.azure.
com
Preparations – Azure VM
first_name last_name VM VM (landing page)
Davíð Baldursson 201 http://lvvws201.northeurope.cloudapp.azure.com
César Costa 202 http://lvvws202.northeurope.cloudapp.azure.com
Pablo Espartero López 203 http://lvvws203.northeurope.cloudapp.azure.com
Simon Fischer 204 http://lvvws204.northeurope.cloudapp.azure.com
Hannes Geske 205 http://lvvws205.northeurope.cloudapp.azure.com
Christof Huysmans 206 http://lvvws206.northeurope.cloudapp.azure.com
Lina Jancyte 207 http://lvvws207.northeurope.cloudapp.azure.com
Natalie Karolak 208 http://lvvws208.northeurope.cloudapp.azure.com
Sebastian Klaus 209 http://lvvws209.northeurope.cloudapp.azure.com
Jussi-Pekka Litmanen 210 http://lvvws210.northeurope.cloudapp.azure.com
Gabriele Oriti 211 http://lvvws211.northeurope.cloudapp.azure.com
Timothy Pauwels 212 http://lvvws212.northeurope.cloudapp.azure.com
Michael Platl 213 http://lvvws213.northeurope.cloudapp.azure.com
Matthias Rabus 214 http://lvvws214.northeurope.cloudapp.azure.com
Hauke Schuldt 215 http://lvvws215.northeurope.cloudapp.azure.com
Morten Sørensen 216 http://lvvws216.northeurope.cloudapp.azure.com
Tommy Svendsen Møballe 217 http://lvvws217.northeurope.cloudapp.azure.com
Pieter Verbeke 218 http://lvvws218.northeurope.cloudapp.azure.com
Joey Zuber 219 http://lvvws219.northeurope.cloudapp.azure.com
Matthew Zygmunt 220 http://lvvws220.northeurope.cloudapp.azure.com
Scope
Scope
• How to change your mindset to include writing automated tests into your
development process

• Understanding the benefit of the automated test

• You may have to sell internally the idea of allowing more time in developing
• project
• product

• Best practices for developing your own test codeunits

Workshop Goal

Making first steps in writing automated tests in NAV making use of

•Testability Framework

•Standard libraries
Agenda

Morning Afternoon

Why Automated Testing Hands-on

Testability Framework Take-away / Do’s & Don’ts

Test Design
Why automated testing
a business justification
 Everyone expects
Even when they
what you do, to be
don’t know what
perfect first time
they really want
every time

They expect a Oh and the

The NAV developers role is lifetime warranty, timescales better
hard ! even for what they be yesterday,
don’t currently use instantly is to long

Then your
And that even if
expected to
you did write the
remember, every
original code!
last detail, forever
 Many more deployment cycles than
historically
• Monthly CU’s need implementing more regularly
as ‘fixes’
• No choice on Tenerife Saas platform with limited
time to prepare
And our world is Annual & now Biannual Full Version
changing updates force refactoring

More dependencies with Office and API

integration

More complexity with more ISV’s via

Extensions and AppSource
 Timescale Budget Philosophy
reasons Reasons Reasons

Its always • Signoff of

requirements or
design
• The test budget
was used in the
analysis or
• The client doesn’t
see the need to
spend the time

testing • Development
overran (its not a
precise science)
development
phase
• Sales didn’t factor
in the need to test
• Develop fast & fix
it in next release,
(Microsoft style?)
• Preparation of

that gets test data

• Rework was
required
at all

squeezed • The client doesn’t

have the required
people available
• Its too close to the
mandatory go-live
to have time
 Your clients and colleagues expect instant
perfection
•Blaming the specification is just an excuse
•You have to know the full implications of
every change you make
Its your reputation that suffers •Any errors they find in testing are all your
fault

But How?
• When you have little extra time
• And clients demand ever more productivity
 it’s not hard –
build it once –
it’s just a small
use forever
new skill

go on, on top VS Code,

Automated Testing is your
answer
of/compared Docker,
to Extensions V2

it’s easy!
01 02 03 04 05 06 07
More reliable Defined signed More Run whenever it Its definitive Unintended use Your test library
design with up off use cases permutations helps without rather than is highlighted to go with your
front test are quickly waiting for data subjective even years later code library
definition possible prep

Lose less sleep and reduce your stress

 Once they’ve Management like Once learning
Who enjoys testing,
experienced it they the reduced risk curves is over, it can
not you but not
won’t want and higher often be quicker
them either
anything else satisfaction than manual

It lasts forever, Spend your future

every object set It enables complex adding new
release can have a repeatable code, features instead of
full test chasing bugs

Selling it to your clients & colleagues

 So enough justification

let’s see when and how it works!

Automated Testing - When

Each time code is changed

To allow rerun of test collateral

frequently …

… to show that already tested existing

functionality is still working as it should
Automated Testing - When
Existing code is being modified
frequently
Business critical feature is being
changed
New (complex) feature
•added to existing code
•integrated with existing code
Old code refactored
•to make it better maintainable
•to make it scalable
Incorporate Microsoft releases /
updates
Automated Testing

Repeatable

&

Fast
Testability Framework …

History Purpose
NAV Test Framework (NTF) Testing app code
•UI based automated tests •No load test
•C# •No multiuser execution
•Time consuming
•No config test
Multiple
•Builds per day Running isolated
•Versions •Data created of no importance
•Localization •Only result matters, i.e. success or
failure
Introduction
•In platform
• NAV 2009 SP1
•Headless (at first)
•Approx. 10 times faster
 Testability Framework …
… for Dummies
Test Design
Test Design

Architecture Patterns

Functional test vs. unit test Test Case Patterns

•4 Phase testing
NAV vs. structured programming •ATDD
• Acceptance Test-Driven Development
Headless vs. UI • preferred pattern
Positive & Positive-Negative Test Data Patterns
Data agnostic •Built Fixture
•Lazy Setup
Terminology & Patterns •Fresh Setup
•xUnit Test Patterns
Test Case Patterns - 4 Phase testing

Setup

Exercise
Verify

Teardown
Test Case Patterns - ATDD

Given
•Setup

When
•Trigger
Then
•Verification
Test Data
aka Fixture or Test Fixture

Setup at different stages in tests

•CRONUS
• Prebuilt Fixture

•Data shared by multiple tests

• Lazy Setup or Shared Fixture
• master, supplemental & setup data

•Test specific data

• Fresh Setup or Fresh Fixture
• document & custom master data
Test Design
But even more important is …

Test Plan
Test Plan

Create before app coding

Review to get agreement
Based on requirements/use cases
•Use Cases = Test Plan
•Minimalism
Test Plan

Create before app coding

Review to get agreement
Based on requirements/use cases
•Use Cases = Test Plan
•Minimalism
DEMO | Test Tool
 Hands-on
~
Test Fixture
Test Fixture - Example
[SCENARIO 0008]

When deleting a seminar with comments lines these lines should also be
deleted
Test Fixture - Example
[SCENARIO 0008]

When deleting a seminar with comments lines these lines should also be
deleted

// [SCENARIO 0008] When deleting a seminar with comments lines these

// lines should also be deleted
// [GIVEN] A seminar with comment lines

// [WHEN] Deleting the seminar

// [THEN] Verify that linked comment lines have been deleted

Hands-on 1 – Create Seminar Registration (0204)

Create seminar registration and

Posting/Document Date

•Create Seminar Registration

•Check that Posting/Document Date have been
populated with WORK DATE
Tip: [SCENARIO 0015]
Hands-on 1 – Create Seminar Registration (0204)

// [SCENARIO 0204] When creating a seminar registration Posting Date and

// Document Date are populated with WORKDATE

// [GIVEN] Seminar Setup with No. Series set for seminar registration

// [WHEN] Creating a seminar registration (header)

// [THEN] Posting Date and Document Date are equal to WORKDATE

 Hands-on
~
Handling Errors
Handling Errors - Example
[SCENARIO 0030]

When deleting a seminar registration with status <> Canceled an error

should be thrown
Handling Errors - Example
[SCENARIO 0030]

When deleting a seminar registration with status <> Canceled an error

should be thrown

// [SCENARIO 0030] When deleting a seminar registration with Status <>

// Canceled an error should be thrown
// [GIVEN] A seminar registration

// [WHEN] Deleting the seminar registration an error is asserted

// [THEN] Verify that Status <> Canceled error was thrown

Positive-Negative

ASSERTERROR

Rollback
Assert Library
Hands-on 2 – Seminar No. Series (0004)

Manual Not allowed

•Create Seminar
•Change No. Field
•Test that error is shown

Tip: [SCENARIO 0002]

Hands-on 3 – Seminar Registration (0032)

Delete with Charges when Status = Canceled

•Create Seminar Registration with Status = Canceled

•Create Charges for it
•Delete Seminar Registration
•Handle error

Tip: [SCENARIO 00030][SCENARIO 00033]

Hands-on 2 – Seminar No. Series (0004)

// [SCENARIO 0004] When changing the No. on seminar and applicable no.
// series does not allow this, an error should be thrown

// [GIVEN] A seminar and No. Series with Manual Nos. = No

// [WHEN] Changing the seminar no.

// [THEN] Verify right error was shown

Hands-on 3 – Seminar Registration (0032)

// [SCENARIO 0032] When deleting a seminar registration with charges an

// error should be thrown when Status <> Canceled

// [GIVEN] A seminar registration with charges

// [WHEN] Deleting the seminar registration an error is asserted

// [THEN] Verify right error was shown

INTERMEZZO | Test Isolation
Test Isolation
Test Runner
TestIsolation property
Disabled (default value)
•Do not roll back any changes to the
database
Tests are not isolated from each other
Codeunit
•Roll back all changes to the database
after each test codeunit executes
Function
•Roll back all changes to the database
after each test function executes
Test Function
TransactionModel property
AutoCommit (default value)
• Commit is issued at the end of test function
Standard Error handling
AutoRollback
• Transaction is rolled back after test execution
Calls to COMMIT will fail with an error
None
• Test function does not have open write
transaction
At the end of each trigger changes are
committed to the database
If error occurred changes are rolled back at
the end of the transaction.
Used primarily with TestPages
 Hands-on
~
Action on Page
TestPage - Example
[SCENARIO 0001]

OnOpenPage should create a record in Seminar Setup table

TestPage - Example
[SCENARIO 0001]

OnOpenPage should create a record in Seminar Setup table

// [SCENARIO 0001] OnOpenPage should create a record in Seminar Setup

// table
// [GIVEN] No record exist in Seminar Setup table

// [WHEN] Opening Seminar Setup Page

// [THEN] A record should exist in Seminar Setup table

Hands-on 4 – Seminar No. Series (0005)

AssistEdit

•Open Seminar Page (New)

•Select AssistEdit to No. field
•Handle ModalPage
•Check that No. field is populated
Hands-on 4 – Seminar No. Series (0005)

// [SCENARIO 0005] Create seminar no. using the AssistEdit functionality

// [GIVEN] A new seminar record is being created

// [WHEN] Pressing AssitEdit action on seminar no. / No. Series page is

// opened handled by ModalPageHandler

// [THEN] Seminar no. is populated

INTERMEZZO | Debugging
Debugging Tools
Dynamics NAV Test Tool

Dynamics NAV Debugger SQL Server Management Studio

Hands-on
~
Enqueue
Enqueue - Example
[SCENARIO 0028]

Change Seminar Price on header having registered lines

[SCENARIO 0201]

Change Seminar Price on header having unregistered lines

Enqueue - Example
[SCENARIO 0028]

Change Seminar Price on header having registered lines

// [SCENARIO 0028] Change Seminar Price on header having registered

// lines
// [GIVEN] A seminar registration with lines and Seminar No. set

// [WHEN] Changing Seminar Price

// [THEN] Verify that seminar price has changed on header and lines
Hands-on 5 – Seminar Registration (0026)

Select Room when ..

(Room."Maximum Participants" <> 0) AND

(Room."Maximum Participants" < "Maximum
Participants")

•User creates Seminar Registration

•Select room with Room."Maximum Participants" < "Maximum
Participants"
•Handle confirm
Hands-on 5 – Seminar Registration (0026)

// [SCENARIO 0026] When a user selects a room on a seminar registration with too
// low capacity (i.e. max. participants) for selected seminar
// user will be asked if room should still be selected and max.
// participants on seminar registration should be adjusted

// [GIVEN] A user creating a seminar registration with max. participants set

// [GIVEN] A room resource with max. participants < sem. reg max. participants

// [WHEN] User selects room on seminar registration header and select yes in
// confirm

// [THEN] Room No. on seminar registration is set right

// [THEN] Max. participants on seminar registration is equal to max. participants on
// room resource
Take-away 1
Nightly test run
Take-away 2

Dos Don’ts
Design tests before app code is ready Do not wait till app code ready to
•Unit Tests and Use Case tests design your tests
Code minimalistic Run in production
Code generic
Test fixture
Version management on test code
Use standard libraries
References
NAV Blogs
•https://msdn.microsoft.com/en- •http://www.fluxxus.nl
us/dynamics-nav/testing-the- •http://thenavblog.com/
application
xUnite Test Patterns
•http://xunitpatterns.com
Four-Phase Test
•https://robots.thoughtbot.com/four-
phase-test
Acceptance Test–Driven
Development
•https://en.wikipedia.org/wiki/Accept
ance_test%E2%80%93driven_develop
ment
Thanx