Provide Interface/Fake for the ScriptEngine To Support Unit Testing

[MF91WorkPS]

Hi,

we often create HostObjects that have methods calling an async method in a background service. We need to inject the ScriptEngine into the constructor to use the Task to Promise conversion via the task.ToPromise() extension method. Example:

    using Microsoft.ClearScript;
    using Microsoft.ClearScript.JavaScript;
    using Microsoft.ClearScript.V8;
    using System.Diagnostics.CodeAnalysis;
    using System.Threading.Tasks;
    
    public class ScriptEngineBuilder
    {
        ScriptEngine Build()
        {
            var runtime = new V8Runtime();
            var engine = runtime.CreateScriptEngine();

            var backgroundService = new BackgroundService();
            var exampleBridge = new ExampleBridge(
                engine,
                backgroundService);

            engine.AddHostObject("exampleBridge", exampleBridge);

            return engine;
        }
    }    

    public class ExampleBridge
    {
        private readonly ScriptEngine _scriptEngine;
        private readonly IBackgroundService _backgroundService;

        public ExampleBridge(
            ScriptEngine scriptEngine,
            IBackgroundService backgroundService)
        {
            _scriptEngine = scriptEngine;
            _backgroundService = backgroundService;
        }

        [SuppressMessage("Style", "IDE1006:Naming Styles", Justification = "By design: Function available in JavaScript")]
        public dynamic someFunction()
        {
            var backgroundTask = _backgroundService.DoSomethingAsync();

            return backgroundTask.ToPromise(_scriptEngine);
        }
    }

    public interface IBackgroundService
    {
        Task DoSomethingAsync();
    }

    public class BackgroundService : IBackgroundService
    {
        public async Task DoSomethingAsync()
        {
            await Task.Delay(10);
        }
    }

Because deployment and testing of our solution is highly automated, we try to cover any code with Unit and Integration Tests to prevent bugs from being rolled out. However, there are no public interfaces for the abstract class ScriptEngine or its implementations (V8ScriptEngine, ...). Also you cannot implement a fake ScriptEngine, because there are some internal dependencies (IUniqueNameManager, ...). This makes testing with common frameworks such as Moq not easy. E. g. this does not work:

    using Microsoft.VisualStudio.TestTools.UnitTesting;
    using Moq;

    [TestCategory("Unit Testing")]
    [TestClass]
    public class ExampleTests
    {
        private readonly Mock<IBackgroundService> _backgroundServiceMock;
        private readonly Mock<IScriptEngine> _scriptEngineMock;

        private readonly ExampleBridge _exampleBridgeInTesting;

        public ExampleTests()
        {
            _backgroundServiceMock = new Mock<IBackgroundService>();
            _scriptEngineMock = new Mock<IScriptEngine>();

            _exampleBridgeInTesting = new ExampleBridge(
                _scriptEngineMock.Object,
                _backgroundServiceMock.Object);
        }
    
       //Test methods
    }

Would it be possible to add a public interface for the ScriptEngine or its implementations? Or alternatively provide a fake such as a NullScriptEngine?

[ClearScriptLib]

Hi @MF91WorkPS,

Thanks for reaching out. We have a couple of questions.

you cannot implement a fake ScriptEngine

Script engines are mostly self-contained and have no major dependencies – no I/O, no UX, etc. Why would you want to mock one? In fact, ClearScript's original purpose was for test automation 😊

Also, your code refers to IScriptEngine. Where and how is that defined? Or is that a placeholder for the ClearScript interface you're proposing?

Thanks!

[MF91WorkPS]

Hi @ClearScriptLib,

thank you for the quick response. Yes, the interface IScriptEngine is a placeholder for the interface I am proposing. From my point of view, there are two big benefits of using an interface instead of a concrete implementation in a Unit Test:

1. The goal of a Unit Test is to determine whether the code in the class ExampleBridge is correct - independent from the implementation of dependencies such as the BackgroundService or the ScriptEngine. If I initialize a V8ScriptEngine and use the object for Unit Testing, a Unit Test may fail because the code in V8ScriptEngine constructor or in a called method of the V8ScriptEngine has changed due to a ClearScript update. In my opinion such issues should be caught by Integration Tests. When an issue occurs, it is faster to identify the root cause and fix it.
2. I can simulate exceptions or return values from methods more easily and test how my code performs in the different situations. For example, ScriptEngine.evaluate(...) returns an object, such as an int or string, or the method throws an exception. Since I only have a concrete class, I need to write a script to reproduce each case. Obviously, it is relatively easy and fast to create a script that returns an int. But let's assume I want to write script that tests how my code handles a ScriptEngineException with a specific message. With an interface and Moq it is a one liner, e. g. scriptEngineMock.Setup(x => x.Evaluate(...)).Throws(new ScriptEngineException(...)). It is more difficult to write a script to test that.

Please let me know what you think or if you have any follow-up questions.

[ClearScriptLib]

Hi @MF91WorkPS,

Thanks for clarifying your scenario.

To be honest, we're leery of extracting interface versions of ClearScript's public classes. There are quite a few of them, and some are rather large. Our fear is that the duplication between interface and class members could make ClearScript's API more confusing. That API also includes static classes for which we'd need another means of isolation.

Instead, would it not be possible for your application to define IScriptEngine internally and delegate its default implementation to ClearScript? You could limit that interface to features you require, use the mocking tools of your choice, avoid breaking your code when a ClearScript update adds new members, and even switch to a different script engine in the future.

Please send us your thoughts.

Thank you!

[MF91WorkPS]

Hi @ClearScriptLib,

I understand your point of view. Regarding the suggestion: Yes, I can implement IScriptEngine using a facade pattern to enable testing and dependency injection.

Thanks for your time!