public void ShouldHaveEnterpriseFeeling() { var abstractServiceHelperFactoryGeneratorMiddelwarePoolAdapter = new AbstractServiceHelperFactoryGeneratorMiddelwarePoolAdapter(); Assert.IsNotNull(abstractServiceHelperFactoryGeneratorMiddelwarePoolAdapter); }
public void ShouldHaveEnterpriseFeeling() { // Arrange // In the arrange step, you setup all direct inputs. // You will also setup all dependent on components. // System under Test // Use this label as well. In Object oriented code, // you should always have an object. If you don't, for example // when you are using static functions, then your code will end up // procedural, not object oriented. The tests are trying to tell you that. // This here is actually really important. The constructor call is being made // WITHIN the test. Often, this will become very painfull, for example, // when the constructor has tons of dependencies, and needs many other objects // to work. // But again: LISTEN to your tests. If making a CTOR call here is too difficult for you // there might be something wrong with yout code. Maybe the object is doing too much // Maybe the setup is too complicated. // // The name of the Ctor here is also important: You can tell the it is unclear, what this // Thing is supposed to do. // // It is important not to call the object "SUT". This is the meta vocabulary // You should name the object after its role in the world and in the application // SUT labels the object after its role in the test. And you don't really care about // that. The test is a means to an end. var adapter = new AbstractServiceHelperFactoryGeneratorMiddelwarePoolAdapter(); // Act // The act label is to call the method. You should only test direct effects // (so when you put A in, you should get B, but not B'). // You should always test for behavior, never for state. // Assert // In the assert step, you test whether your direct inputs have actually caused // An immediate effect. You test for direct outputs, not for indirect outputs. // Indirect outputs are, for example, writing to a database or to a file. // These are sideeffects. You should test those things somewhere else. // Your units should all be modeled to cause immediate effects. // // Listen to the functional programming guys. They have been trying to tell you // that for ages. Testing stuff that does not have side effects is super easy // // The following is crap. You don't care about whether this thing exists. // You would, however care about its behavior. // Testing null for the result of the adapter's operation // is important Assert.IsNotNull(adapter); }