All Projects → neowit → apexmock

neowit / apexmock

Licence: other
force.com Mock data and fixtures for Apex Unit Tests

Programming Languages

Apex
172 projects

Projects that are alternatives of or similar to apexmock

apex-mocks-stress-test
Testing out FFLib versus Crud / CrudMock
Stars: ✭ 47 (+95.83%)
Mutual labels:  salesforce, apex, sfdc, salesforce-developers, apex-framework, salesforce-apex
NebulaFramework
A development framework for Salesforce's Apex language & the Force.com platform
Stars: ✭ 28 (+16.67%)
Mutual labels:  salesforce, apex, sfdc, salesforce-developers, apex-framework, salesforce-apex
apex-dml-mocking
DML mocking, CRUD mocking, dependency injection framework for Salesforce.com (SFDC) using Apex
Stars: ✭ 38 (+58.33%)
Mutual labels:  salesforce, apex, sfdc, salesforce-developers, apex-framework, salesforce-apex
APEX-Q
A promise library for Salesforce
Stars: ✭ 30 (+25%)
Mutual labels:  salesforce, apex, apex-framework
Script.apex
Evaluate Javascript expressions in Apex
Stars: ✭ 18 (-25%)
Mutual labels:  salesforce, apex, salesforce-developers
apex-rollup
Fast, configurable, elastically scaling custom rollup solution. Apex Invocable action, one-liner Apex trigger/CMDT-driven logic, and scheduled Apex-ready.
Stars: ✭ 133 (+454.17%)
Mutual labels:  salesforce, apex, salesforce-developers
apex-rest-route
A simple framework for building Restful API on Salesforce
Stars: ✭ 75 (+212.5%)
Mutual labels:  salesforce, apex, apex-framework
sf-cross-cutting-concerns
Apex Cross cutting concerns for Salesforce
Stars: ✭ 29 (+20.83%)
Mutual labels:  salesforce, apex, apex-framework
apex-utils
Utility classes for Salesforce Apex development
Stars: ✭ 20 (-16.67%)
Mutual labels:  salesforce, apex, salesforce-developers
apex-tmLanguage
Salesforce Apex Language syntax grammar used for colorization
Stars: ✭ 27 (+12.5%)
Mutual labels:  salesforce, apex, salesforce-developers
R.apex
Functional utility library for Apex
Stars: ✭ 80 (+233.33%)
Mutual labels:  salesforce, apex, salesforce-developers
HTTPCalloutFramework
HTTP Callout Framework - A light weight callout framework for apex HTTP callouts in Salesforce
Stars: ✭ 43 (+79.17%)
Mutual labels:  salesforce, salesforce-developers, salesforce-apex
Apex-Code-Conventions
Apex conventions and best practices for Salesforce Developers
Stars: ✭ 28 (+16.67%)
Mutual labels:  salesforce, apex, salesforce-developers
apex-fp
Functional programming for Salesforce Apex
Stars: ✭ 231 (+862.5%)
Mutual labels:  salesforce, apex, salesforce-developers
ApexTriggerHandler
Another library implements Apex trigger handler design pattern.
Stars: ✭ 40 (+66.67%)
Mutual labels:  salesforce, apex
lwc-modules
Build any LWC you want without ever having to touch Apex
Stars: ✭ 20 (-16.67%)
Mutual labels:  salesforce, apex
Salesforce-Short-Hands
The main purpose of this repository is to put all the utilities in one place so that other developers can get help and they can also contribute to this repo.
Stars: ✭ 31 (+29.17%)
Mutual labels:  salesforce, salesforce-developers
Sweet.apex
Next Generation of Apex Development
Stars: ✭ 43 (+79.17%)
Mutual labels:  apex, salesforce-apex
SFDCRules
Simple yet powerful Rule Engine for Salesforce - SFDCRules
Stars: ✭ 38 (+58.33%)
Mutual labels:  salesforce, apex
salesforce-plantuml
Salesforce app to generate UML class & ER-diagrams from your org data. Leverages the PlantUML library.
Stars: ✭ 89 (+270.83%)
Mutual labels:  salesforce, apex

apexmock

force.com Mock data and fixtures for Apex Unit Tests

ApexMock is a library which can assist in dummy data generation for Apex Unit Tests

This library supports two kinds of testing approaches:

  1. tests working with SFDC DB
  • classes Mock, MockData, MockDataStandard, MockTests, MockUtils
  1. tests not touching SFDC DB and working with Mock Database, see class MockDb
  • MockDb is "in-memory" database which can be used to replace calls to SFDC DB in unit tests

Description below covers Approach 1.
Approach 2 is for more advanced developers and they are expected to figure it out by themselves.

in order to use Mock methods Mock.MOCK_DATA has to be initialised first

	Mock.MOCK_DATA = new MyOrgMockDataSet1();

If Mock.MOCK_DATA is not initialised then by default class named MockData will be used (if existis).

Now you can create some objects

	//create Account and Insert into DB
	//only relevant fields need to be specified, the rest will be taken from MyOrgMockDataSet1
	Account acc1 = (Account)Mock.one('Account', 
					new Map<String, Object>{ 'MyField__c' => 'some-value', 'OtherField__c' => 123}, true); 
	//create account but do not Insert yet
	Account acc2 = (Account)Mock.one('Account', new Map<String, Object>{ 'Name' => 'Acc 2'}, false);
	acc2.MyId__c = '123456';
	Database.insert(acc2);
	...
	//generate and save 2 Opportunities using acc1 and acc2 as their Accounts
	List<Opportunity> opps = Mock.many('Opportunity', 
								new Map<String, Object>{ 'Name' => 'Opp#{COUNTER}', 
								'AccountId' => Id[] {acc1.Id, acc2.Id}}, 2, true); 
	...
	...

	//same as above, but less code, all fields except Accoun.Name are taken from fixtures 
	List<Account> accs = Mock.many('Account', new Map<String, Object>{ 'Name' => 'Acc #{COUNTER}'}, 2, true)

	//using Mock.toIds() so each opportunity will receive its own account Id
	List<Opportunity> opps2 = Mock.many('Opportunity', 
								new Map<String, Object>{ 'Name' => 'Opp#{COUNTER}', 
								'AccountId' => Mock.toIds(accs)}, 2, true); 
	...
	...
	
	//similar to above, but we do not care which Account each Opportunity will be assigned to, 
	//because it is not relevant in our test
	//using Mock.DEPENDS_ON
	Map<String, String> dependsOn = new Map<String, String>{'AccountId' => 'Account', 'My_Related_Object_Ref__c' => 'My_Related_Object__c'};
	List<Opportunity> opps2 = Mock.many('Opportunity', 
								new Map<String, Object>{ 'Name' => 'Opp#{COUNTER}', Mock.DEPENDS_ON => dependsOn}, 2, true); 
								
	//ideally above Mock.DEPENDS_ON should be part of custom data fixture, e.g. in MockData class, but if we need to overwrite Mock.DEPENDS_ON value locally then we can.

Another example, create 3 Contacts using only defined earlier fixtures.
The following single line piece of code will create and save a separate Account for each contact.
See MockDataStandard.CONTACT_VALUES for an example of how DEPENDS_ON is defined.

	List<Contact> opps2 = Mock.many('Contact', 3, true); 

See MockTests.cls for more comprehensive usage examples

Why ApexMock

Two most popular ways to generate test data is

  1. create test data individually for every test like this
		Account acc = new Account (Name = 'Test Acc', BillingStreet = 'Some street', Custom_Field__c = 'some value'...);
		Database.insert(acc);
		Opportunity opp = new Opportunity(AccountId = acc.id, StageName = 'Prospecting', Amount = 100, Some_Field__c = 'value here', ...);
		Database.insert(opp);

Even if in your current test you are only interested in Opportunity.Amount and Account.Custom_field__c, you still have to initialise lots of other fields (e.g. Account.Name) because of validation rules.

  1. In order to minimise repeated code you start writing something like this
		public static Account createTestAccount(String name, String billingStreet, ..., Boolean saveIntoDb) {
			//account initialisation code here
		}

then you use it like so:

		Account acc = MyStaticTestClass.createTestAccount('Some Name', 'Some address', ..., true);

With this approach you have to remember the order of parameters in each createTest[xxx]() method or keep getting back to MyStaticTestClass to check what the order is.

At some point you realise that your test requires 10 Accounts and 20 Opportunities. With approach #1 your test data generation code in each test will be massive, with approach #2 you have to generate at least twice as many createTest[xxx]() methods (one creating single object and 1 creating List of objects).

Later you realise that it would be nice if your static dummy data initialisation code had several very different data sets which you can use to test logic for different business processes (or business units) in your SFDC ORG. i.e. in one case your Contacts must have all standard fields filled in and in Spanish, in the other case you need only LastName and UK PostCode.

How do you solve that?

Will you continue increasing your createTest[xxx]() methods base?
Or will you define different data sets once and then just swap them with one line of code like so:

	Mock.MOCK_DATA = new MyOrgMockDataSet1();
	...
	Mock.MOCK_DATA = new MyOrgMockDataSet2();
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].