Showing posts with label TDD. Show all posts
Showing posts with label TDD. Show all posts

Friday, 1 January 2016

How to use internal type as a unit test argument

Behavioral tests sometimes require access to types which are internal for the SUT assembly. If those types are used in test methods, test assembly name has to be specified through InternalsVisibleToAttribute in SUT assembly. For example, if MyAppTests is a library containing tests for classes within MyApp we have to do the following:
  • in MyAppTests: add the reference to MyApp so all public types are visible
  • in MyApp: specify MyAppTests as the assembly in which internal types are visible. The following line has to be added to MyApp/Properties/AssemblyInfo.cs:

[assembly: InternalsVisibleTo("MyAppTests")]



This makes internal types visible within unit tests. But if we want to pass such types as arguments to unit tests (via TestCase or TestCaseSource attributes), compiler will complain about inconsistent accessibility.

For example, if we have public class (SUT) and internal enum:


and the following test:


Compiler issues an error:

Error CS0051 Inconsistent accessibility: parameter type 'MyEnum' is less accessible than method 'MyClass_Tests.Foo_Does_This_When_MyEnum_Is_Value1_or_Value2(MyEnum)'

Unit test methods have to be public, otherwise unit test runners will not be able to see them or would report that test fails (Nunit Test Adapter also issues error message: "Method is not public"). Unit tests are public API so types of their arguments also have to be public (visible in any assembly, not just in test library).

The solution for this is to pass arguments to test method as type object and then cast them back to the original internal type:


In this particular case, when internal type is enum, we could gave passed type int instead of object but for any other custom internal type, object is the only solution.


Thread which explains reasons why NUnit fails but does not ignore non-public test methods.

Thursday, 31 December 2015

Performance tests

Code can always be optimized in terms of resources used. It makes sense adding performance tests when resources matter and their acceptable usage is a part of the requirements.

Resources can be time, memory, number of threads, sockets etc...but probably most measured are time and memory.

These tests are integration tests because:
- they rely on external factors (they are system- and hardware-dependent)
- asserted results can vary in time
- they can take much time to execute

An example of performance test is verifying that some algorithm performs some task within the acceptable time range.

There is a question on their consistency: e.g. the same algorithm takes more time to execute on slower machines so how to determine pass/fail criteria?



Further reading:
https://en.wikipedia.org/wiki/Software_performance_testing
http://www.dynatrace.com/en/javabook/performance-in-continuous-integration.html
http://stackoverflow.com/questions/751626/performance-testing-best-practices-when-doing-tdd
http://stackoverflow.com/questions/2870322/performance-testing-versus-unit-testing
http://stackoverflow.com/questions/457605/how-to-measure-code-performance-in-net
http://stackoverflow.com/questions/969290/exact-time-measurement-for-performance-testing
http://stackoverflow.com/questions/15181358/how-can-i-unit-test-performance-optimisations-in-c


Thursday, 27 June 2013

Beginning Unit Testing with NUnit in Visual Studio

How to start with NUnit?

Download it from http://www.nunit.org/ and install it. It should be installed at C:\Program Files (x86)\NUnit 2.6.2. (2.6.2 is the current release version in the time of writing this article)

How to organise my projects? Where to put unit tests?

Put the business logic of your app in a class library project (e.g. MyBusinessLogic.dll). Your main app (MyApp.exe) project references this dll. Put unit tests in a separate project (e.g. MyBusinessLogicTester.dll) but within the same solution. MyBusinessLogicTester.dll will reference nunit.framework.dll (located at C:\Program Files (x86)\NUnit 2.6.2\bin) and MyBusinessLogic.dll.

How to run NUnit tests?

In MyBusinessLogicTester project: go to Properties -> Debug. Set Start external program to C:\Program Files (x86)\NUnit 2.6.2\bin\nunit.exe and put MyBusinessLogicTester.dll in Command line arguments field.

Set MyBusinessLogicTester as a StartUp project in your solution and run it. Nunit GUI app (nunit.exe) will open and display all test fixtures and tests in the left-hand side tree view. You can select tests you want to run and then execute them.

If you're running MyBusinessLogicTester tests with ReSharper, make sure MyBusinessLogicTester is marked to be built in the Configuration Manager.


Links and References:
http://www.nunit.org/
http://stackoverflow.com/questions/67299/is-unit-testing-worth-the-effort
http://stackoverflow.com/questions/1365943/how-to-start-unit-testing-or-tdd
http://stackoverflow.com/questions/347156/do-you-put-unit-tests-in-same-project-or-another-project
http://stackoverflow.com/questions/3979855/how-do-i-set-up-nunit-to-run-my-projects-unit-tests
http://stackoverflow.com/questions/759854/how-do-i-run-nunit-in-debug-mode-from-visual-studio
http://stackoverflow.com/questions/3476054/can-unit-testing-be-successfully-added-into-an-existing-production-project-if-s
http://stackoverflow.com/questions/6103807/unit-testing-philosophy