Testing TypeScript with Intern

By on March 24, 2015 9:34 am

Intern

This post has been updated to cover Intern 3.4 and TypeScript 2.3

Intern is a popular JavaScript testing framework, because of its extensive, modular feature set. While Intern is primarily known for testing JavaScript applications, it is also an excellent option for authoring tests with TypeScript. And Intern’s support for source maps makes it easy to track issues back to your original TypeScript source files.

Getting started

To get started, we will test a simple ToDoMVC example application. We’ll begin with specifying a directory structure and providing some example source code.

Directory structure

For the examples in this post, you should use the following directory structure:

todomvc/
        node_modules/intern/
        src/todo/
                 model/
                       SimpleTodoModel.js
                       SimpleTodoModel.js.map
                       SimpleTodoModel.ts
                 tests/
                       intern.js
                       intern.js.map
                       intern.ts
                       functional/
                                  all.js
                                  all.js.map
                                  all.ts
                                  SimpleTodoModel.js
                                  SimpleTodoModel.js.map
                                  SimpleTodoModel.ts
                       unit/
                                  all.js
                                  all.js.map
                                  all.ts
                                  SimpleTodoModel.js
                                  SimpleTodoModel.js.map
                                  SimpleTodoModel.ts
        /typings/intern/intern.d.ts

One of the main challenges with test framework setup are meta problems, including source code directories and configuration. If you’re using a different directory structure, you may need to modify your Intern and/or TypeScript configuration.

Source code

For this example, we have not authored a new example application in TypeScript, but assume we have one of the many ToDoMVC applications and we want to test it. The example tests here will focus on testing the SimpleTodoModel as we have already created examples in the intern-examples repo for this and many other popular ToDoMVC example applications.

Unit tests

Because typical Intern tests are normally authored in JavaScript, most Intern examples are authored with ES5. To help you author TypeScript tests, we will compare JavaScript vs. TypeScript authored tests.

For the SimpleTodoModel example, the JavaScript test source code is:

define([
	'intern!object',
	'intern/chai!assert',
	'todo/model/SimpleTodoModel'
], function (registerSuite, assert, SimpleTodoModel) {
	registerSuite({
		name: 'SimpleTodoModel',
		'default data': function () {
			var emptyModel = new SimpleTodoModel();
			assert.strictEqual(emptyModel.get('id'), 'todos-dojo',
					'Id should default to "todos-dojo"');
			assert.strictEqual(emptyModel.get('todos').length, 0,
					'Todos array should default to an empty array.');
			assert.strictEqual(emptyModel.get('incomplete'), 0,
					'Incomplete count should default to 0.');
			assert.strictEqual(emptyModel.get('complete'), 0,
					'Incomplete count should default to 0.');
		}
});

In this example, we’re creating a set of assertions inside a test suite for our ToDoMVC application.

To accomplish the same with TypeScript, we can leverage TypeScript’s simplified syntax for object literals. And if your application code is authored in TypeScript, you will no longer need to write unit tests that check data types, since the compiler will enforce this for you. You also get the many other advantages any code base receives when using TypeScript (interfaces, enhancements to the language, etc.).

Here is the same example test suite authored in TypeScript:

import * as assert from 'intern/chai!assert';
import * as registerSuite from 'intern!object';
// Assume that we now have a version of our model in TypeScript
import * as SimpleTodoModel from 'todo/model/SimpleTodoModel';

registerSuite({
	name: 'SimpleTodoModel', 
	// Assume we have a promises interface defined
	'default data'() {
		var emptyModel = new SimpleTodoModel(),
			id:string = emptyModel.get('id'),
			length:number = emptyModel.get('todos').length,
			incomplete:number = emptyModel.get('incomplete'),
			complete:number = emptyModel.get('complete');
		assert.strictEqual(id, 'todos-dojo',
					'Id should default to "todos-dojo"');
		assert.strictEqual(length, 0,
					'Todos array should default to an empty array.');
		assert.strictEqual(incomplete, 0,
					'Incomplete count should default to 0.');
		assert.strictEqual(complete, 0,
					'Incomplete count should default to 0.');
	}
});

How does this work?

It is important to remember that just like TypeScript applications, you will only be able to run tests when they have been converted to JavaScript. Fortunately the TypeScript compiler will very easily compile to JavaScript in several different module formats, including AMD or UMD, along with source maps. As such, test modules are imported with the TypeScript import statement in your code and then converted to AMD for testing.

Configure and compile

To test with Intern, you specify a configuration file, which can be done with either JavaScript or TypeScript.

To compile your source code and tests, you’ll add the relevant compiler settings to your tsconfig.json:

{
	"version": "2.3.4",
	"compilerOptions": {
		"declaration": false,
		"experimentalDecorators": true,
		"module": "umd",
		"moduleResolution": "node",
		"noImplicitAny": true,
		"noImplicitThis": true,
		"outDir": "_build/",
		"removeComments": false,
		"sourceMap": true,
		"strictNullChecks": true,
		"target": "es5"
	},
	"include": [
		"./src/**/*.ts",
		"./tests/**/*.ts",
		"./typings/index.d.ts"
	]
}

You’ll also want to include the relevant type related packages in your package.json, and any specific versions of typings that might be needed in typings.json.

TypeScript typings for Intern

The Intern 3.4 release includes its own typings which are available when installing Intern. The forthcoming Intern 4 release is authored in TypeScript.

Functional tests

Functional tests work in the same manner as unit tests, but leverage Intern’s Leadfoot implementation of the WebDriver API. With JavaScript, a ToDoMVC functional test example for submitting a form looks like this:

define([
    'intern!object',
    'intern/chai!assert',
    'require'
], function (registerSuite, assert, require) {
    var url = '../../index.html';
    registerSuite({
        name: 'Todo (functional)',
        'submit form': function () {
            return this.remote
                .get(require.toUrl(url))
                .findById('new-todo')
                .click()
                .pressKeys('Task 1')
                .pressKeys('\n')
                .pressKeys('Task 2')
                .pressKeys('\n')
                .pressKeys('Task 3')
                .getProperty('value')
                .then(function (val) {
                    assert.ok(val.indexOf('Task 3') > -1, 'Task 3 should remain in the new todo');
            });
        }
    });
});

Rewritten in TypeScript, the test is:

import * as assert from 'intern/chai!assert';
import * as registerSuite from 'intern!object';

var url = '../../index.html';
registerSuite({
    name: 'Todo (functional)',
    'submit form'() {
        return this.remote
            .get(require.toUrl(url))
                .findById('new-todo')
                .click()
                .pressKeys('Task 1')
                .pressKeys('\n')
                .pressKeys('Task 2')
                .pressKeys('\n')
                .pressKeys('Task 3')
                .getProperty('value')
                .then(function (val:string) {
                    assert.ok(val.indexOf('Task 3') > -1, 'Task 3 should remain in the new todo');
            });
    }
});

TypeScript + Intern examples

If you need more inspiration in creating tests with TypeScript and Intern, the following projects contain unit and functional test examples:

Caveats

Most previous limitations and caveats have been resolved with recent releases of Intern and TypeScript. Most remaining complexity around testing with TypeScript are being resolved with the Intern 4 release.

Testing alias modules

A common pattern with Intern is to create modules that simply include all of your tests to run inside a module. This makes it easy to maintain a list of tests outside of your Intern configuration file, a good DRY practice. However, if you import a module and never reference it, the TypeScript compiler skips it. If you are writing a module that is simply a list of all of your other modules to test, this won’t work. The workaround is to simply refer to the module within your list of tests.

For example, if you were to do this normally with a JavaScript set of tests:

// all.js
define([
'./model/SimpleTodoModel',
'intern/node_modules/dojo/has!host-browser?./store/LocalStorage',
'intern/node_modules/dojo/has!host-browser?./form/CheckBox'
], function () {});

So then with TypeScript, you would need to do the following:

// all.ts
/// <amd-dependency path="intern/node_modules/dojo/has!host-browser?./store/LocalStorage" />
/// <amd-dependency path="intern/node_modules/dojo/has!host-browser?./form/CheckBox" />
import * as SimpleTodoModel from 'todo/model/SimpleTodoModel';
SimpleTodoModel;

Notice the single reference to SimpleTodoModel immediately after importing the module. As an aside, in this example, we’re assuming that we would rewrite the ToDoMVC example in TypeScript, but some of its dependencies are still authored in JavaScript. It may be more useful to view a complete example of this test module pattern.

Non-TypeScript paths

TypeScript does not concern itself with the paths to JavaScript AMD modules as it does not load or read them. TypeScript depends on the definitions in the *.d.ts files. It is up to you to make sure your AMD paths are correct in your application when you run it, but this is irrelevant for TypeScript compilation. Note that relative paths in the TypeScript compiler are calculated relative to wherever the *.d.ts file is, not the actual JavaScript AMD module files.

Further reading

Learning more

There is much more detail to authoring TypeScript tests, but the main takeaway is that you simply author tests with valid TypeScript, and compile to AMD for testing. If you’re not sure where to start with Intern, or you need some help making your TypeScript source code more testable, or want assistance in defining a testing strategy for your organization, SitePen can help!

Getting Help With Typescript and Intern

Workshops Logo

SitePen’s TypeScript for the Enterprise Developer and Intern workshops are a quick way to jumpstart your journey into the modern era!

Support Logo

SitePen Support. Receive timely answers and relevant code examples from early adopters and active users of TypeScript and the creators of Intern.

Let's Talk! Logo

Let’s talk about how we can help your organization benefit from the use of TypeScript in your next project.

Contact Us Logo

Have a question? We’re here to help! Get in touch and let’s see how we can work together.

Comments

  • Dasa

    Thanks for the this post. I just noticed that the links to the intern and leadfoot typings are 404. I think you also have an extra ‘:’ on line 9 of the unit test example.

  • Thanks Dasa, the typings moved from a branch to master between the time I wrote this post and it was published. And thanks for catching the typo. Both items are fixed now.

  • Anonymous

    Download the intern.d.ts file, fire up TS 1.5beta, and take this for a spin.

    ///
    import registerSuite from ‘intern!object’;
    import assert from ‘intern/chai!assert’;

    registerSuite({
    name: ‘REST Tests’,

    ‘ALM-18888′() {

    console.log(“OMFG intern tests in ES6 style!”);

    }
    });

  • Yes, indeed, if you are using 1.5, you can use ES6/ES2015 module syntax. I’ll update the examples

  • Anonymous

    Download the intern.d.ts file, fire up TS 1.5beta, and take this for a spin.

    ///
    import * as registerSuite from ‘intern!object’;
    import assert from ‘intern/chai!assert’;
    import mysql = require(‘intern/node_modules/dojo/node!mysql’);

    registerSuite({
    name: ‘REST Tests’,

    ‘ALM-18888′() {

    var connection = mysql.createConnection({
    host : ‘opm-int’,
    user : ‘root’,
    password : ‘ugauga’
    });

    connection.connect();

    connection.query(‘SELECT 1 + 1 AS solution’, function(err, rows, fields) {
    if (err) throw err;

    console.log(‘The solution is: ‘, rows[0].solution);
    });

    connection.end();

    }
    });

  • thepetesmith

    Dylan I have it working fine with ts 1.5 doing import * as foo from bar; I am trying to not use require(‘foo’) if I can avoid it. Thoughts?

  • It’s fine for your own modules, but I have no idea how that would work for pulling in Intern’s own modules, which are available as AMD or CJS modules…

  • thepetesmith

    import * as registerSuite from ‘intern!object’;
    import * as assert from ‘intern/chai!assert’;

    Seems good?

  • The registerSuite and assert modules are not ES6 modules, so I don’t think you can just import them with ES6 semantics and have them work as expected. Wouldn’t assert and registerSuite be non-callable objects with this approach?

  • I guess, there is amistake in the article, near the phrase “Here is the same example test suite authored in TypeScript:”. In the code sample below that phrase, there is some HTML-markup that shoudn’t actually be a part of that code sample. Actually, inside that code sample there is two different code samples, and a piece of HTML markup between them.

  • also, the “any specific versions of typings that might be needed in typings.json” link leads to package.json , not to typings.json

  • Thanks, clearly my recent updates for TS 2.2 did not preserve the formatting. I’ve fixed both of the issues you’ve reported @tolik89u:disqus .

  • Is it possible to use Intern with webpack & TypeScript (& React & Redux)? On StackOverflow, I’ve been said it’s not currently. ( http://stackoverflow.com/questions/43679035/how-to-use-intern-with-typescript-and-webpack ) Is that true? As I understand, React is widely used with webpack. Cannot I use Intern with them?

  • Hi @tolik89u:disqus , yes, it is possible (and certainly easier with webpack 2 than it was with webpack 1). We currently use it with our work on Dojo 2 which uses webpack 2, Intern 3.4, and it is authored in TS (see https://github.com/dojo/widget-core/ for one repo that leverages this stack). There are a few webpack plugins we leverage that help make the experience a bit smoother.

    It is something that will be easier with Intern 4, where as well as rewriting in TS, we’re removing the loader that’s included in Intern and leaving module loading up to you, so it becomes conceptually easier to get things running as the confusion between Intern’s loader and your application loader goes away.

    If you’re feeling adventurous, Intern 4 is at a point where you could try out what is in master, it’s still pre-beta and the documentation isn’t really there yet, but we’re getting to a point where things are pretty stable.

  • If you use webpack in Dojo 2, why then there is no webpack.config.js file in its repo, nor it is mentioned in .gitignore file? And also, why then the “test” script command in package.json uses grunt as a bundler, and not webpack? Isn’t this a mistake, that Dojo 2 uses webpack? And if it does use, then could you please point out, where should I look in Dojos’s code to see, how this all is connected to each other? (I mean webpack + Intern + TypeScript.) I can see that tests are written in TypeScript, and I can see that they are runned via “grunt test” command, but I cannot understand, what then happens under the hood, there is nothing appropriate in the Gruntfile.js, and thus, I cannot understand, how I can repeat the same technique in my project. Is this some kind of magic? :D Could you please help me and point that out?

  • Note that our webpack config is centralized for Dojo 2 at https://github.com/dojo/cli-build/blob/master/src/webpack.config.ts . We’re typically still using UMD as an intermediary for testing, and then webpack’s ability to combine UMD modules for the build optimization.

  • Daniel Martín

    Hi Dylan. Thanks a ton for the article! It’s the only one out there covering the TypeScript + Intern topic.

    I managed to setup things based on your instructions, with a couple of caveats that perhaps you know how to circumvent.

    The first one is that when I import the following two things:
    import registerSuite = require('intern!object')
    import assert = require('intern/chai!assert')

    I get the following compile errors:
    error TS2307: Cannot find module 'intern!object'
    error TS2307: Cannot find module 'intern/chai!assert'

    For whatever reason, if I include intern itself right before, even though I don’t use it directly, TypeScript stops complaining:
    import intern = require('intern')

    I would like to avoid having to do this.

    The other issue is that, from the tests, I’m restricted in the way I have to import things. Let’s say I have a file x.ts and another one x.test.ts; and a third one index.ts exporting x from x.ts. All in the same directory.

    With this setup, I can normally import x from x.test.ts by doing:
    import { x } from '.'

    But this would yell the run-time error (when running intern-client) “Error: Failed to load module”. I have to explicitly refer to the file to make it work:
    import { x } from './x'

    And I also would like to avoid losing the flexibility of importing from the “index” files, specially since TypeScript seems to be totally fine about it, but is Intern the one complaining.

    In case it helps, this is how my TypeScript configuration looks like:
    {
    "compilerOptions": {
    "target": "es6",
    "module": "amd",
    "moduleResolution": "node",
    "rootDir": "src",
    "outDir": "build/tests",
    "sourceMap": true,
    "noImplicitAny": true,
    "suppressImplicitAnyIndexErrors": true
    }
    }

    While my intern.js file looks like:
    define({
    suites: ['build/tests/**/*.test.js'],
    excludeInstrumentation: true,
    filterErrorStack: true
    })

    Thanks in advance for your time!

  • Kitson P. Kelly

    While Intern includes its typings, they are not found automatically by the TypeScript compiler. You need to utilise the types option in your tsconfig.json:


    {
    "compilerOptions": {
    "types": [ "intern" ]
    }
    }

  • Daniel Martín

    Thanks for the quick response, Kitson. Following your advice, I ended up having this in the configuration file:

    "typeRoots": [
    "./node_modules/@types",
    "./node_modules/intern/typings/**/*.d.ts"
    ]

    However, everything works the same as before, meaning none of the issues were solved.

  • Paul Shannon

    Does the same thing happen if you use the `types` compiler option?

    The typeRoots compiler options doesn’t support a globbing pattern for resolving names. See: https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#types-typeroots-and-types

    If you’re still having issues, I would recommend running tsc with –traceResolution to see how it’s trying to resolve those dependencies.

    As a work-around, you can always include intern at the top of your configuration. It’s used in several dojo2 projects: https://github.com/dojo/core/blob/master/tests/intern.ts#L1

  • Kitson P. Kelly

    For clarity, I didn’t recommend changing the typeRoots. The typing for Intern at the moment are not modular/UMD typing (they are ambient/global) and so either need to be included via a triple slash ref or by telling the compiler to include it in the scope.

  • Kitson P. Kelly

    Sorry to contradict, but I wouldn’t recommend that old style of importing, it can cause side effects and will not be elided by the compiler. We need to change that for Dojo 2.

  • Daniel Martín

    I had already solved the problem by importing “intern” explicitly. At the end, I’m using a triple-slash reference. I don’t like much neither of the options, but never mind.

    What about the other issue I mentioned, any clue on that? (Namely, the fact that the tests wouldn’t run if I import from “index.ts” files, even after a successful compilation.)

  • Jason Cheatham

    When your test module requires ‘.’, the AMD loader treats the module’s current directory as a package and tries to load the default module (Dojo uses ‘main.js’ as the deafult) from that package. For example, if your code is in a src/ directory and tries to import ‘.’, at runtime the loader will try to load src/main.js.

    To fix this, add a package definition for the directory containing x.test.js to your test config file, and set its main attribute to ‘index.js’, like:


    packages: [
    { name: 'src', location: 'src', main: 'index.js' }
    ]

    Note that importing modules will be simpler in Intern 4 (currently in alpha), which doesn’t use an AMD loader by default. Syntax like import { x } from '.'; will work out-of-the-box because the runtime module loading semantics will more closely match TypeScript’s loading semantics.

  • Daniel Martín

    Thanks for the help! I’m happy to hear about Intern’s future plans. I didn’t manage to get your trick to work, though. My new intern.js file is:

    define({
    suites: ['build/tests/**/*.test.js'],
    excludeInstrumentation: true,
    filterErrorStack: true,
    loaderOptions: {
    packages: [{name: 'src', location: './src/utils', main: 'index.js'}]
    }
    })

    While my directory structure looks like:

    src
    core
    utils
    x.ts
    x.test.ts
    // Other files, each containing a function that I would like to unit-test...
    intern.js
    package.json
    tsconfig.json
    ...

  • Jason Cheatham

    The package name should be 'src/utils' rather than just 'src'. A package name typically corresponds to a location; when your x.test.ts file imports ‘.’, it’s loading the implicit package src/utils.

  • Daniel Martín

    I had tried already, but same thing… Sorry. And thanks again.

    I’m quite amazed how hard is to setup the very basic stuff with TypeScript while Intern itself is written on it. (Specially given their “Just Works” statement.)

  • Almost all problems with testing frameworks are what I would describe as meta or configuration driven. There’s no shortage of configuration things that can go wrong with modules, paths, typings, etc. It’s pretty likely that it’s one silly thing that is not as expected, and these things can be difficult to track down unfortunately. Keep in mind that Intern 4 is written in TS, whereas Intern 3 was not. We’re hoping these types of configuration challenges become easier to track down as part of this refactoring effort. Anyway, I’m unfortunately not seeing anything obvious for why you cannot import without the path.

  • Jason Cheatham

    Sorry about that — a package of ‘src/utils’ won’t work. You’ll actually need to use a single-word package name, like ‘utils’, and then using a loader map to map from ‘src/utils’ to the ‘utils’ package, like:


    loaderOptions: {
    packages: [
    { name: 'utils', location: 'src/utils', main: 'index.js' }
    ],

    map: {
    '*': {
    'src/utils': 'utils'
    }
    }
    }

    Regarding how hard setting things up is, TS and Intern each make assumptions about your project. As long as you’re working within either set of assumptions, things generally will just work. However, when you work in both environments at the same time, some default assumptions will clash. For example, TS and Node use index.ts/index.js as a default package file, while Intern uses main.js. TS and Intern support package mapping (where you can point a package name at some directory in your project), while Node does not.

    Intern 3 (the current version) isn’t actually written in TS, although it includes TS typings. Intern 4 is written in TS, and it makes fewer assumptions about how your project is organized, so it will handle situations like this more cleanly.

  • Daniel Martín

    How much time did you say before Intern 4 is out? Just kidding a bit… No luck with your latest solution.

  • Jason Cheatham

    What error are you seeing? I setup a simple project with a structure like the one you’ve described (at least as I understand it), and it works well enough (at least for my trivial test case).

  • Daniel Martín

    Thanks for taking the time! I appreciate a lot your intentions. This is the exact error I’m seeing:

    Error: Failed to load module build/tests/tests from /home/daniel/Code/xyz/build/tests/tests.js (parent: build/tests/utils/x.test)
    at FSReqWrap.readFileAfterOpen [as oncomplete]

    I’ve prepared a git repository with a simplified version of the project reproducing the error – communicating efficiently here is proving hard. If you have the time, these are the instructions to reproduce the issue:


    $ git clone https://github.com/inad9300/intern-bug-hunting
    $ npm i
    $ npm run compile # works :)
    $ npm run tests # doesn't work :(

  • Jason Cheatham

    Ah, seeing the actual project layout helps. :)

    The packages and map statements aren’t agreeing with the repo layout — try
    packages: [
    {name: 'tests', location: 'build/tests/tests', main: 'index.js'},
    {name: 'utils', location: 'build/tests/utils', main: 'index.js'}
    ],
    map: {
    '*': {
    'build/tests/tests': 'tests',
    'build/tests/utils': 'utils'
    }
    }

  • Daniel Martín

    I see! It makes sense, the packages have to point to the post-compilation version of the code, since that’s what Intern cares about, not to the TypeScript source.

    I’ve seen that you also found my StackOverflow post and tried to get to a solution there. Thanks for everything :)

  • This is an example of a screenshot reporter in JS:


    define([
    'intern/dojo/node!fs'
    ], function (fs) {
    function Reporter() {
    this._remotes = {};
    }
    Reporter.prototype = {
    constructor: Reporter,
    sessionStart: function (remote) {
    this._remotes[remote.session.sessionId] = remote;
    },
    sessionEnd: function (remote) {
    delete this._remotes[remote.session.sessionId];
    },
    testFail: function (test) {
    if (!this._remotes[test.sessionId]) { return; }

    return this._remotes[test.sessionId]
    .takeScreenshot().then(function (image) {
    fs.writeFileSync(test.id + '.png', image);
    });
    }
    };
    return Reporter;
    });

    And then in your Intern config:

    {
    // ...
    runnerClientReporter: {
    waitForRunner: 'fail'
    },
    reporters: [
    'examples/ScreenshotReporter'
    ]
    }

    You could author the same in TS if you would like of course. Usage of it would then be quite similar in ES or TS.

  • fireundubh

    How do I use intern.ts for configuration instead of intern.json?

    How do I run intern so that it executes *.ts test scripts?

    Using intern.json, I’m getting “Error: Unable to load /tests/unit/all.”

    What’s supposed to go into the tests/intern.js and tests/intern.js.map files?

    What’s supposed to go into the tests/**/*.js and tests/**/*.js.map files?

    What’s supposed to go into typings/intern/intern.d.ts? I thought intern types were set up in tsconfig.json.

    This tutorial is a bit thin on details. Can you set up an example Intern TypeScript project on GitHub?

  • @fireundubh:disqus Thanks for the feedback. This post needs an update to reflect the changes in Intern 4 (it was originally authored against Intern 3.x). We’ll answer your questions, update the post, and put together an example Intern TS project as soon as possible.

  • fireundubh

    Thanks. And, yeah, I saw the huge version differences last night – after 8 hours of banging my head against the wall. The official documentation is a mishmash of 3.x and 4.x examples…

  • Yes, apologies, transitions are difficult, and 4.0 was just released. Hopefully your head and wall feel better soon. :)

  • fireundubh

    Oh! I didn’t connect your name to Intern and the LinkedIn post I linked on GitHub until now. I thought I was on a third-party consultant’s blog or something. Sorry if I was a bit hard on you or the project.

    As an aside, the other day, I was able to get Intern set up for strictly Node.js testing, but Intern with Selenium is still a no-go. For your future documentation efforts, I would suggest adding more information about working with Intern 4 and Selenium, as well as with WebStorm.

  • Fair enough, unlike most third-party consultants, we actually build a lot of OSS things. We just try to remain as neutral and unbiased as possible in our communications so we can provide solid guidance. We’ll see what we can do to address your points raised next week hopefully.