How do you unit test office.js app code?

Question

Are there any common practices, frameworks or patterns for unit testing office.js based code? Given the large number of the components in thr object model, it's impossible to mock calls to office.js. Is there something like a karma launcher to launch test code in to a test container task pane app? Anybody has worked out an effective way to test code that interact with office.js?

Coniine

Answer 1

Here's what I ended up doing:

1. Added a new Task Pane App project to the solution
2. Included the Jasmine Standalone zip from https://github.com/jasmine/jasmine/releases
3. Made TaskPane app's Manifest Source Location point to the SpecRunner.html
4. Modified boot.js to replace the execution of test specs on window.load to execute on Office.initilize.

Coniine

Answer 2

I think you should unit test Office.js based code the same way you would do for "standard" javascript code. Indeed, Office.js is just another javascript dependency like JQuery etc.

Of course you should not include Office.js in your test page and replace Office object by a mock. You can have a look at Sinon Js a javascript mocking framework.

When you write unit test, you isolate a piece of code (a class or a module) which is called the System Under Test (SUT). If you based your addin on a Single Page Application framework such as Angular, a SUT can be a controller. Then you can inject the Office object as a dependency, in real context this will be the real Office from Office.js. In test, this will be a mock.

Americanize

In theory, yes, this is how we'd go about it. However, if you take for example the code at github.com/OfficeDev/office-js-docs/blob/master/docs/excel/… mocking Office objects would end up being an excessive amount of work. You'd have to mock workbook, sheet, range, charts and all sub-objects. So, mocking doesn't seem to be an option. Just as jquery unit tests don't create a mock DOM but, runs on a HTML page, I would imagine Office.js based tests need to run on a container Task Pane app. – Coniine

@Coniine if you do only Unit Test (no integration testing) you do not need to mock everything, just the methods/properties of Office used by your SUT. This should not be a big amout of work... – Americanize

@Sameera, I would add to that that realistically, what I would do is write standalone functions that accept input/output -- and unit-test them, Office.js completely aside. And then I would have another set of integration tests that do run inside of Excel, and are as close to user interactions as possible, modulo being programmatically-driven instead of UI-driven – Circumferential

@MichaelZlatkovsky If you take the sample code I've linked in the first comment, function loadDataAndCreateChart that populates a given range, on the activesheet, creates a chart from that data and formats it. Obviously, this isn't best practice as the fn doesn't adhere to Single Responsibility Principle. But, such code could be quite common given that it's more efficient to manipulate Office.js Proxy Objects in bulk and sync with Excel than to make multiple calls to Excel after doing minor units of work (which would be testable). Is this perception wrong? – Coniine

@Sameera, sorry, it looks like this thread had slipped off my radar. If you still have a question here (and actually, it sounds like it's a different question than testing anyway), would you mind starting a different StackOverflow thread? – Circumferential