1

We are developing Office Add-ins (apps for office) and we want to automate the testing for continuous delivery by using VSTS.

Because the Add-ins are web apps I wanted to use tools like Selenium, but that doesn't seem to work because the app is not in a browser (but is using the IE engine from within Word)

I tried using the Coded UI tests from visual studio, but they are not functioning correctly. It seems to handle some basic UI events, but even simple things typing text result in unpredictable behavior. (missing characters, clicking the wrong items).

I hope someone else has some experience on how to do this?

Thank you very much.

Leander van Eck
  • 123
  • 10
Christian
  • 269
  • 1
  • 10
  • What the version of the office you are working with? – Eddie Chen - MSFT Apr 29 '16 at 03:00
  • And this article may help you: https://vstotest.codeplex.com/releases/view/86997 – Eddie Chen - MSFT Apr 29 '16 at 03:24
  • Thank you @Eddie-MSFT for your help. I work with Office 2016. The document you refer to is UI Testing for VSTO. I've used that in the past, and that worked well. But now we are making the HTML 5 Office Add-ins. I'm not sure what the problem is, but when I use the Coded UI test on these HTML5 apps, things go wrong. For example: uIVV9D67ABA502D448CD81Edit.Text = "testing"; about 50% of the times, one or more characters are missing in the input field. So I don't know if the codedUI tests are the proper tool to use on Apps for Office. – Christian Apr 29 '16 at 11:08

1 Answers1

2

What we have done with our add-in, for automated testing of the task pane, is to mock the Office API methods we are using, and inject the mocked Office object into our code (vs importing the real Office API script and referencing the global). This has worked well for us, using Mocha+Chai+Sinon+Enzyme for our React-based add-in.

Devin Canterberry
  • 160
  • 8
  • Hi Devin, Thanx for your comment. We currently lookin into Ranorex. But I'll keep you suggestion in mind for the future. – Christian Jun 02 '17 at 07:38