Unit testing the JS and OverwolfPlugin integration

  • Feature Description:

I would like to be able to test the integration of my app with my C# plugin (I validate each of them independently, but I still would like to validate the full integration).
Today, the OverwolfPlugin is not usable in unit tests because it depends on overwolf.extensions.

What I would like to have is a similar way to load and interface with the plugin in my tests.

  • impact for my app: [low, mid, high, show-stopper].

low/mid

  • What is your current pain point?

I have no way to automatically regress the new developments. This is particularly painful when a new Hearthstone version is released, as it can change the plugin’s output, which means I have to regenerate all my mocks.

  • What do you have in mind to solve it?

A test version of OverwolfPlugin :slight_smile:

note for stuff: after FR is accepted, add a link to the internal ticket.

checking this issue and let you know ASAP. thanks

1 Like

@sebastientromp sorry I’m not sure that I understand.
Can you please clarify? what do you mean by:

  • OverwolfPlugin is not usable in unit tests because it depends on overwolf.extensions
  • when a new Hearthstone version is released, it can change the plugin’s output

Hey, sorry for not being clear.

In a unit test context, I don’t have access to overwolf.extensions, since as far as I know the API is injected by the platform. Or is there a way to include the scripts in a unit test context?
Since the OverwolfPlugin 's implementation relies on the OW API, this means I can’t use it in a unit test context.

And the other line is not really important, you can forget it :slight_smile:

@sebastientromp are you familiar with this sample project?

Yes, that’s what I started from :slight_smile:

This is a pure C# project though, and I want to test the integration with the plugin from the Javascript part.
The bridge today is made by a piece of code (included in the sample app) called overwolfplugin.js

The piece of code that prevents me from reusing it in my unit test setup is this:

function _initialize(callback) {
		var proxy = null;

		try {
			proxy = overwolf.extensions.current.getExtraObject; // This doesn't work in a UT environment
		} catch (e) {
			console.error("overwolf.extensions.current.getExtraObject doesn't exist!");
			return callback(false);
		}
...

@sebastientromp Hi. the function getExtraObject() instantiates the plugin object.
I consult with our R&D, which suggested that you can mock getExtraObject to return a mock plugin object.

My main question is this - how can I return the real plugin object, so that I can write integration tests that include both the JS and the real C# plugin?

If you are using the OverwolfPlugin class then you can create a mock object.

Another solution we’ve seen before is having a mock as default and then overwriting the mock when you actually create the object. And so, in a unit test you can refrain from creating the object.

Yes I understand that. It’s what I’m using today.
My point is however to build full integration tests, i.e. tests that don’t rely on a mock, but that directly integrate the plugin’s logic.
In other words, I would like to do

log file (produced by the game)
-> plugin (does some parsing) 
-> events (emitted by the plugin) 
-> app (business based on the events) 
-> output

and check the output based on the input log file.

I could test that, for a given log file, the right events are produced. Then I could test that, given a specific set of events, the app logic is correct.
This is what I’m doing, to some extent.
However, every time I’m adding an event, or modifying some logic inside an event (which I can’t predict at the time I’m writing the tests), I need to revisit / regenerate ALL the tests to make sure things still work, which I don’t have the time to do, as opposed to just re-run the full logic on the same input logs.