Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 262 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 385 SQL Performance
- 33 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
Unittesting and mocking?
johsv448
Member Posts: 2
Hi everyone this is my first post here so please be gentle.
I was recently granted the honor of my company to start getting to know the inner workings of NAV and now BC14 on-prem in order to be a better orderer for our dynamics partner. Being a C#-developer I soon became interested in getting to know how to code in C/AL and how to make configurations with out having to involve hour partner in every little small change we need to make.
We now have a need to calculate the price for our orders without actually creating a sales order. The creation of sales orders are handled by our accounting department at a later time, we would like to get an estimate price before that is done. In order to not create duplicate code that calculates the cost for our order and make maintaining this logic more of a nightmare than it already is, I would like to refactor the code into separate functions that can be called separately.
The current flow looks something like "Clickbutton to create sales order" -> CreateFilterForReport -> validate selection(ReportObject) -> more validation(CodeUnit) -> split order into calculatable parts(Same CodeUnit) -> calculate price and create salesorder intertwined(Same CodeUnit). And every step invokes the next, it's not like the are invoked one at a time. No the steps call upon each other to achive this.
I have no idea if it is considered good practice to build flows like this but I do know that this is fairly business critical, so I am not too keen on going to town tweaking this. Of course there are no unittests what so ever, so that is were I would like to start.
So to get to my question: Is it possible to mock calls to tables such as sales header and sales order line, so I can start refactoring this mess and still be certain things are executed in the way it is supposed to?
From what I have heard it is possible to set a variable in C/AL to be temporary and that the records written during the execution to be stored only in tempdb, but wouldn't that require me to somehow change the codeunits variable setting from non-temp to temp during the run of the unittest?
I was recently granted the honor of my company to start getting to know the inner workings of NAV and now BC14 on-prem in order to be a better orderer for our dynamics partner. Being a C#-developer I soon became interested in getting to know how to code in C/AL and how to make configurations with out having to involve hour partner in every little small change we need to make.
We now have a need to calculate the price for our orders without actually creating a sales order. The creation of sales orders are handled by our accounting department at a later time, we would like to get an estimate price before that is done. In order to not create duplicate code that calculates the cost for our order and make maintaining this logic more of a nightmare than it already is, I would like to refactor the code into separate functions that can be called separately.
The current flow looks something like "Clickbutton to create sales order" -> CreateFilterForReport -> validate selection(ReportObject) -> more validation(CodeUnit) -> split order into calculatable parts(Same CodeUnit) -> calculate price and create salesorder intertwined(Same CodeUnit). And every step invokes the next, it's not like the are invoked one at a time. No the steps call upon each other to achive this.
I have no idea if it is considered good practice to build flows like this but I do know that this is fairly business critical, so I am not too keen on going to town tweaking this. Of course there are no unittests what so ever, so that is were I would like to start.
So to get to my question: Is it possible to mock calls to tables such as sales header and sales order line, so I can start refactoring this mess and still be certain things are executed in the way it is supposed to?
From what I have heard it is possible to set a variable in C/AL to be temporary and that the records written during the execution to be stored only in tempdb, but wouldn't that require me to somehow change the codeunits variable setting from non-temp to temp during the run of the unittest?
0
Answers
If you want to compare to real-live data it would be easiest to copy the DB (since youre OnPrem) and work on that copy, this will also assure you don't destroy anything.
If you want to get into Unit-Testing in BC/AL I highly recommend Luc's book: amazon.com
You can use temporary Records(!) to buffer Data In-Memory. We use that to create database-records for in-between steps that we don't want commited to the database (since we are not object oriented and can make stuff up on the go
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
Did you ever figure this out? I would love to be able use mocks