Contents tagged with Unit test
Today I want to write a really short description of different kind of tests, which can be perfomed by code.
Unit test: Specify and test one point of the interface of single method of a class. This should have a very small and well described scope. Complicated dependencies and activities to the outside staff are stubbed or mocked.
Integration test: Test the correct co-operation of multiple subsystems. There is whole ecosystem here, from testing integration between two classes, to testing integration with the production environment.
Smoke test (AKA Load test, AKA Sanity check): A simple integration test where we just check that when the system under test is … more
today I want to make another description of how to cover with Unit Tests Graphs in Acumatica.
First of all I want to say that Acumatica controllers or as Acumatica names them graphs do not have any way to inject any dependency from interface. In such case it can be useful idea to use Microsoft Fakes library.
So in order to unit test Acumatica code you will have a need to make mix of Acumatica code with Microsoft shims. Imagine that you have following graph declaration:
public class PAllocs : PXGraph<PaymentsAllocation>
and somewhere in your graph you have method like this:
[PXButton(Tooltip = "Saves values from grid")]
[PXUIField(DisplayName = "Save" … more
Examples of Mock usages
Mock - is a simple and lightweight isolation framework, which is built on the basis of anonymous methods and expression trees. To create them it uses code generation, thus allowing to mock interfaces, virtual methods (and even protected methods) and does not allow to mock non-virtual and static methods.
At market exists only two frameworks that allow to mock anything. These are TypeMockIsolator and Microsoft Fakes, available in Visual Studio 2012 and higher. These frameworks, unlike Mock ( which uses code generation) use CLR Profiling API, allowing to mock any method even for static, virtual and private methods. IMHO they are good for testing legacy code … more
today some notices of what is considered to be a good unit test.
1. Tests should be independent and isolated.
For example if you have functions a, b, c tested, then sequence of test shouldn't affect the result.
2. Each test should test single behaviour or logical staff.
If to speak about phone example, calling and sending sms shouldn't be in one functoin
3. Clear purpose understood.
4. Don't test the compiler ( like writing/reading to db )
5. Reliable and repetable ( give the same result ).
6. Quality the same as other parts of solution.
7. Valuable for developers more
just short notice of NUnit function Assert.That
public void CheckAddition()
Assert.That(CalculatorClass.Minus (5, 2), Is.EqualTo(3));
public void CheckAddition()
//old styel Assert.AreEqual(3, CalculatorClass.Minus (5, 2));