Skip to content

Testing

How to Test Your Internal Classes in C

One of the most important concepts of object-oriented design is encapsulation. You try to hide all the internal things of a class from the other developers and only offer them a subset of functionality to use. You can achieve this by setting an appropriate access modifier for your methods and classes:

  • public: The type or member can be accessed by any other code in the same assembly or another assembly that references it.
  • private: The type or member can be accessed only by code in the same class or struct.
  • protected: The type or member can be accessed only by code in the same class, or in a class that is derived from that class.
  • internal: The type or member can be accessed by any code in the same assembly, but not from another assembly.
  • protected internal: The type or member can be accessed by any code in the assembly in which it is declared, or from within a derived class in another assembly. (as in protected OR internal)
  • private protected: The type or member can be accessed only within its declaring assembly, by code in the same class or in a type that is derived from that class. (as in private OR protected)

Different Styles for Examples in BDD

Behavior-driven development (short BDD) is all about examples. They are used to explain what should happen when certain events occur and what exactly the meaning of a certain requirement is. So far all is simple and straight-forward. The challenges come with writing those examples. There are different ways to express the same ideas and not every style works with every audience.

xUnit.net Cheat Sheet for NUnit Users

I am currently learning the xUnit.net framework as part of a new project I work on. For the last years I used NUnit for my unit and integration tests. Conceptually those two libraries aren't that different. However, the naming of attributes and what is possible in sharing setup & clean-up code makes it worth to take a deeper look.