Automated Testing OpenXML SDK

Question

I'm implementing ms word document generation using content controls and OpenXML SDK. I'd like to have some automated testing for that code (unit tests or some easy UI automation tests).

Does anyone has expericnce with testing MS Word document generation? What are the possible options?

Thanks in advance!

Ribal

Why does OpenXML unit testing have to be any different from standard. Are you trying to validate if the document can open in word or if it will look alright? – Viceregent

It's not diffrent, it's just technically diffucult. Typical test is Arrange-Act-Assert. So the question is how can we easily do last part - Assert. Possibly using some word automation or UI automation framework, but I don't see an easy way to do this. Thus I endup with tests generating report and opening in word, so I manually check if report is fine. It's not a "pure" unit test, but better than running full app to generate needed reports. Also I'm intrested in testing code that works directly with Open XML, all other pieces I have separated and tested with usual unit tests. – Ribal

Answer 1

No, I haven't done unit testing of MS Word Document generation, but as Ingó Vals says, it shouldn't be any different from any other form of unit testing.

1) [Optional - to ensure that you understand correct usage of the SDK for your needs]. Work out how your app should drive the SDK. Write some test scripts that mimic intended functionality and ensure that the Word documents they generate meet your expectations.

2) Create an interface (or interfaces) that contain methods that correspond to the functionality that you need for your documentation generation. Note: the interface does not need to offer the full functionality of the OpenXML SDK - only the functionality that you need for your application.

3) Create a concrete implementation of your interface, which forwards calls to the OpenXML SDK

4) Utilise the interface you created in your application to perform document generation.

5) Use NUnit and NMock (or similar) to write unit tests that drive the generation layer of your application. These tests should use a mocked interface, rather than an instance of the concrete implementation. You can now assert in your tests that your generation layer behaves as you expect.

Mosasaur

Thanks for the answer, but the thing is that I'm intrested in testing code that directly manipulates Open XML SDK. All the rest I can separate or mock, that's clear. Using mocks insdead of actually calling Open XML SDK is not to my liking, as what I want to test is that my code works fine with SDK. Someone may argue that it's not a pure unit test, but that what is realy missing in my current test. – Ribal

What I described is unit testing your code. I would call what you want an integration test. In which case I guess you could get the SDK to output Word XML and write a method that compares the resulting DOM with the DOM you expect. – Mosasaur

Yep, unit or integration or UI automation or what will work. To sumarrize any type of automated testing that will allow to do verification (Assert part of the test). Will check DOM comparison. Thanks a lot! – Ribal

I aggree with Seb Rose here. Create the document or document part you expect to come out ( with all the bells and wistles to ensure you test everything ) and compare it to what you create in the test. – Viceregent

Answer 2

I am actually doing something similar with the OpenXML SDK for spreadsheets and I actually just write OpenXML api code that opens the file from a stream for the purpose of testing. Unit Tests don't really tell you enough since you need to know if it is a valid file.

// There should be a sheet for every team
[TestMethod]
[HostType("Moles")]
public void CaseExportTeamSheetsTest()
{
    IRepository<ServiceTbl, ServiceTbl> ServiceRepository;
    CaseController target;
    BuildCaseControllerMoledCases(out ServiceRepository, out target);
    FileStreamResult actual = target.Export();   using (SpreadsheetDocument spreadsheetDocument = SpreadsheetDocument.Open(actual.FileStream, false))
    {
        var services = ServiceRepository.All;

        foreach (var item in services)
        {
            // get a worksheet foreach service
            var sheets = spreadsheetDocument.WorkbookPart.Workbook.Descendants<Sheet>().Where(s => s.Name == item.ServiceName);
            Assert.IsTrue(sheets.Count() > 0);
        }
    }

    actual.FileStream.Close();
    actual.FileStream.Dispose();
}

Elmerelmina

Answer 3

Warning regarding OpenXml Sdk 2.0 and valid code....

I have generated OpenXml Powerpoints documents that validates using XML SDK 2.0 tools and works in Office 2007 on my PC but when opening the document on another machine using Office Powerpoint 2007 it complains and says the format is not valid

XML Sdk 2.0 http://www.microsoft.com/downloads/details.aspx?FamilyId=C6E744E5-36E9-45F5-8D8C-331DF206E0D0&displaylang=en

Champion

Answer 4

The high-level approach for testing Microsoft Word document generation is the following:

1. Define test cases, where each one consists of:

   • the generator inputs, i.e., the data to be used in generating Word documents; and
   • the expected output in Open XML format, i.e., the Open XML markup representing a correctly generated Word document.

2. Write test methods, using your favorite unit testing framework (e.g., xUnit). Using the typical "Arrange, Act, Assert" pattern, those test methods:

   • set up the generator, generator inputs, and expected generator outputs as required;
   • run the generator, providing the generator inputs and capturing the actual generator outputs; and
   • compare the actual generator outputs with the expected generator outputs.

It is very easy to retrieve the actual generator output with the Open XML SDK. When comparing actual and expected outputs, you can apply different levels of markup filtering or simplification. For example, you could focus on the essential markup such as the content controls (w:sdt elements) mentioned in the question.

Md