Dan Maharry

Are bug fix tests unit or integration?

by

Jeremy Miller asked how do you know if your TDD approach is working earlier today. And then I wrote the following test which covers a particular bug \ feature of xsd.exe I found a while ago. It's incomplete, but then I started worrying, is this approach right? I'm testing one method which takes a schema and returns a CodeNamespace which has been altered. I need to make sure the result addresses the bug that was discovered which this test seems to do. But is it a unit test? Shouldn't it have fewer asserts as I've read in the past? Shouldn't I be satisfied with the tests I've also written on routines that perform the tweaking on the CodeNamespace once it has been generated, but which do not make sure that all those smaller routines work together to produce the overall result? What are your thoughts out there. 

[Test]
public void Convert_ComplexTypeHasElementInChoiceWithNoType
_GeneratedCodeFixesTypeOfObjectBug()
{
XmlSchema schema = sb.CreateSchemaContaining(new XmlSchemaObject[] {
sb.RootElementWithSeparateType(rootElementName, rootTypeName),
sb.NamedComplexTypeContaining(rootTypeName, 
sb.ChoiceOf(sb.DateStringAndEmptyElements(
dateElementName, stringElementName, emptyElementName)))
});//Convert it
CodeNamespace ns = sc.ConvertSchemaToCodeNamespace(schema);//Check that the empty class has been generated
CodeDomAssert.AssertClassExists(ns, emptyElementName + "Class");//Find the original class and check it has a choice element in it //which isn't typeof(object) but which is typeof(emptyElementClass)foreach (CodeTypeDeclaration typeDec in ns.Types)
{
if (typeDec.Name == rootTypeName)
{
//Check that the choice element is fielded by a property of type 
//system object tagged with
//[XmlElement("emptyElement", typeof(emptyElementClass))]
//Create attributes to check
CustomAttribute emptyElementAttribute = new CustomAttribute(
CustomAttributeType.Simple, elementAttributeName,
new AttributeArgument[] {
new AttributeArgument(
CustomArgumentType.Simple, String.Empty, emptyElementName),
new AttributeArgument(
CustomArgumentType.TypeOf, String.Empty,  
emptyElementName + "Class")
});
CodeDomAssert.AssertFieldExists(
typeDec.Members, MemberAttributes.Private, "System.Object",
HelperFunctions.DefaultXsdGeneratedFieldName(defaultGeneratedPropertyName));
CodeDomAssert.AssertTaggedPropertyExists(
typeDec.Members, defaultGeneratedPropertyName, "System.Object",
true, true, 
HelperFunctions.DefaultXsdGeneratedFieldName(defaultGeneratedPropertyName),
new CustomAttribute[] { emptyElementAttribute });
}
}
}

MbUnit and nUnit VS Templates

by

If, like me, you're slowly getting into test-driven development, it becomes apparent that there are several ways to create a class library and a set of tests that challenge it in Visual Studio. Then it becomes obvious that the best way to do it and not leave test code in your releases is to create something like this where the tests are in a separate project.

mbunitprojecttemplates

To speed up the creation of solutions like these, I've created two templates to plug into Visual Studio to do it for you. There's one for testing with MbUnit 2.3 RTM and one for NUnit2.2.9. Download the one you want to your VS2005 Project Templates folder and then create a new project. You'll see the options to use the templates automagically.

vsprojecttemplates

Let me know how you get on and if you'd change them in some way.

So you think you write unit tests?

by

Found a great post on blogs.msdn which ties in neatly with some of the stuff that Roy Osherove is writing in his Unit Testing book. Realising that a unit test is not always a unit test can be quite important. Knowing what it is helps too.

Here’s a quick list of some of the different kinds of tests. It’s not a complete list, but it should cover a lot of common terms you’ll often see tossed around at work or in the literature. As you can see, there can be some overlap between the terms: for example, you may have a developer test which is also a unit test which may also be a check-in test as well. But keep in mind they are all orthogonal concepts, and can vary independently.

  • Unit test: tests a function or class in complete isolation from other code in the system. If the item under test has dependencies, those dependencies are replaced by fake (“mock”) objects. If it touches the filesystem, hits a database, access a network, or displays UI, it’s not a unit test. Unit tests have practically no setup and run extremely fast.
  • Integration test: tests the interaction of two or more classes and functions working together. Multiple layers are usually involved. Whereas unit tests ensure that the “bricks” in your system are square, solid, and uniform, integration tests ensure that they are stacked up correctly and glued together the right way. A test that verifies data entering one end of a pipeline will come out the other end is an integration test. So is a test that verifies that data is unchanged when round-tripped through a reversible process.
  • Characterization test: tests unknown or “legacy” code for response to stimuli. Often used during refactoring to ensure that the behavior of the code is unchanged. Characterization tests are often written in total ignorance of the inner workings of the code, and the expected results are often completely unknown as well.
  • Developer test: any sort of test (unit test, integration test, acceptance test, stress test) written by a developer as a design and development aid, as opposed to a QA engineer ensuring the correct operation of the code after the it has been “thrown over the wall” to Test.
  • Automated UI test: a test that simulates a fixed series of user interactions, such as mouse clicks and key presses, and the resulting UI is then compared to an expected result.
  • Regression test: a test which ensures that bugs that get fixed stay fixed.
  • Check-in test: a series of tests used to verify that the product is not accidentally broken by new features or bugfixes, prior to the change being submitted. Check-in tests do not exhaustively test everything (they still need to run in a reasonable amount of time), but they should give good coverage over certain areas. Check-in test suites are usually mostly unit tests, because unit tests execute so quickly. But integration tests and regression tests can be good candidates for inclusion as well.

Source: So you think you write unit tests? Think again.

Some Test-Driven Development Links

by

With the TDD series in full swing - any feedback out there? anyone? - some interesting TDD and coding links have been coming up recently