NEW: Dependency on edge.js has been removed, the npm runs entirely in the npm process only (no clr code running behind the scenes) which provide an easier setup and much better performance.
The NuGet packages use semantic versioning like this:
x.y.z => Major.Minor.Patch x: stands for the major version. Any breaking changes will update this number. y: minor version. Any minor updates add new functionality without breaking changes. An example of these would be a new operator or a new fake message executor. z: patch. Any update to this number means new bug fixes for the existing functionality. A new minor version might also include bug fixes too.
Please consider the below guidelines for contributing to the project:
Priority: Given the overwhelming number of issues and pull requests, between the 2 FakeXrmEasy projects we'll review Pull Requests first, then any outstanding issues. We encourage you to resolve / extend issues by yourselves, as a community, and we'll prioritise those first because we know (as mantainers) the effort it takes.
We'll thank you forever and ever.
If you don't know how to resolve something or are not familiar with pull requests, don't worry, raise the issue anyway. Those will be revised next.
When raising an issue:
- Please provide a sample unit test to reproduce any issues detected where possible. This will speed up the resolution.
- Attach all generated early bound typed entities required (if you're using early bound).
If you're using the framework, please do Star the project, it'll give more visibility to the wider community to keep extending and improving it.
- If you're a business / company who delivers solutions on top of the Power Platform, you can help make OSS sustainable while getting more visibility by becoming a sponsor. Please reach out to me for sponsorship enquiries.
To be able to unit test Dynamics CRM Web Api calls as easily as possible, given that:
The focus will be on unit testing Web API calls, not the Xrm Page, as there are other projects for that already (see https://github.com/camelCaseDave/xrm-mock).
Executing web api queries doesn't involve any access to the DOM, which means we could even use Node for testing. This is also the same for the Xrm Page, where we shouldn't access the DOM (i.e. via jQuery) as it is unsupported. The only exception would be custom web resources but we can live with it because we can still separate JS logic from the logic which accesses the DOM (HTML).
We want to run unit tests as fast as possible
Given the above, the approach chosen is the following:
So roughly, the following steps:
Check this repo for a sample code project.
- Queries: Implemented $select
- Queries: Implemented $filter (relational and boolean expressions)
- Queries: Implemented $filter functions (startsWith, endsWith, substringof)
- Queries: Implemented $top functions
- Create: basic create
- Update: basic update
- Delete: basic delete
- Retrieve: basic retrieve, retrieve with $select
- Ability to add custom Web API functions / custom action mocks: please check test/XrmFakedContext/fake_message_executor_tests.ts for examples
To Do (you can use addFakeMessageExecutor function to mock any response while these are not yet implemented as a workaround) :
- Retrieve with alternate keys
- Retrieve a single property value
- Retrieve navigation property values (similar to $expand for queries)
- Create related entities in one operation
- Associate entities on Create
- Delete single property values
- Update with data representation returned (simulate update + get message)
- Update by single attribute (PUT)
- Limit upsert via headers (If-Match, If-Not-Match)
Queries: Implement $expand functions
Queries: Implement $orderby functions
Queries: Implement lookup filtering
Optimistic concurrency simulation