Some of my test classes pass when I run them in MavensMate, but fail when I run them in Apex Test Execution in the org itself.
Apex Test Execution:
And just because I think it might be useful for a good answer, the error(same error for all 5 methods) that I get in Apex Test Execution is:
System.DmlException: Insert failed. First exception on row 0; first error: MIXED_DML_OPERATION, DML operation on setup object is not permitted after you have updated a non-setup object (or vice versa): GroupMember, original object: Account: 
So the question is:
What could be the reason of such a different behaviour?
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
This sort of thing has been going on since the Summer ’08 release. See How to avoid MIXED_DML_OPERATION error in Salesforce tests that create Users.
Essentially, there are certain types of sObjects that you can’t perform DML operations on in a test case and then proceed to modify other types of sObject. See sObjects That Cannot Be Used Together in DML Operations
The following sObjects can’t be used with other sObjects when performing DML operations in the same transaction:
You can only insert and update a group member in a transaction with other sObjects in Apex code saved using Salesforce API version 14.0 and earlier.
The typical solution to this is to use
System.runAs to separate the sObject types that can’t have DML performed together.
Other Uses of runAs
You can also use the runAs method to perform mixed DML operations in your test by enclosing the DML operations within the runAs block. In this way, you bypass the mixed DML error that is otherwise returned when inserting or updating setup objects together with other sObjects.
Why is MavensMate behaving differently than the Salesforce UI?
Again, this oddity comes back to how the test is being run. I encountered it in 2011 when Eclipse gave different test results to the Salesforce UI. External tools like MavensMate and the Force.com IDE rely on using the public APIs to perform test runs.
In the case of MavemsMate, it currently runs the test cases via the mm executable with the
test operation (possibly unit_test). Maybe if you can read node.js fluently you can find which specific API call is being made.
Anyway, one or more of the Salesforce APIs that can be used to run test cases produce a different result to the standard Salesforce UI. There are several options to running test cases, such as the Tooling API, Metadata API or the Apex API. Then there are SOAP and REST versions available.
This may be as specific as the API version that the calls are being made against. The Salesforce UI, including the developer console, will be using current API version. Whereas the external tooling may be several releases behind.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0