Test Automation for Dynamics 365 session slides at CRM Saturday Madrid:
Why Unit Testing?
Why FakeXrmEasy?
How it works
Demo with VS2017's Live Unit Tests
26. 1. Why FakeXrmEasy?
CRM SDK is pretty much “static” composed of:
- CRUD
- Queries
- Other messages
27. 2. Why FakeXrmEasy?
Prior to 2014… started doing unit testing with
FakeItEasy and….
- Found myself doing a lot of repetitive
tasks…
- … and many problems
28. Problems with existing general
purpose .NET frameworks
- Generic & Complex
- Mocking Queries is REALLY hard
- Multiple CRM messages to mock
29. Problem #1: Complexity
var mock = new Mock<IOrganizationService>();
mock.Setup(service =>
service.Create(It.IsAny<Entity>()))
.Callback((Entity e) => {
e.Id = id;
entities.Add(e); })
.Returns((Entity e) => id);
35. “It does so during development,
before deploy, functional
testing, UAT, Staging and, of
course, Production.”
36. How it Works?
- 1 single ctx.GetOrganizationService() call needed.
- Query Engine: QueryExpression, LINQ, FetchXml,
QueryByAttribute
- Fake Messages: many implemented, but not all of them…
yet (pull requests pls!)
38. In-Memory DB
In-Memory DB (this is actually way more simple than it sounds!)
- 2 Levels of Dictionaries
- First level indexes by Entity Name, second level indexes entity
records by Id (Guid) to simulate the different CRM tables.
39. In-Memory DB
In-Memory DB (this is actually way more simple than it sounds!)
Fast!
Mainly because memory is several orders of magnitude faster than disks or
network.
Also, because even in-memory, dictionaries gives us generally Θ(1) algorithm
complexity: Constant Access Time for CRUD operations. Given O(n) the
worst case.
CRUD
40. What about the Query Engine…?
In-Memory DB (this is actually way more simple than it sounds!)
Query Engine
46. To recap…
- 1 single ctx.GetOrganizationService() call needed. No mocks!
- Query Engine: QueryExpression, LINQ, FetchXml, QueryByAttribute
- Fake Messages: many implemented, but not all of them… yet (pull
requests pls!)