Running tests on Typescript source code Versus the generated JavaScript

Question

In a web project where TypeScript is used to program the entire application, front-end and back-end, and as well as tests. Then it is all compiled and deployed as JavaScript;

What is desirable to run the tests on during deployment. Does it make more sense to run it on the TypeScript source code directly? Or does it make more sense to run it on the resulting generated JavaScript (which is later deployed to server)

Remember that depending on which it is run on, it has some minor implications on things like code-coverage reporting for example.

One school of thought is to run it on the TypeScript source code, because that is what the programmer is producing and has direct control over.

On the other hand, it is the JavaScript generated code that ultimately runs after it has been deployed.

Is there an accepted pattern to this?

Test the TS source code. You say that the JS generated code is what is ultimately run - but the generated JS code is also what is ultimately tested by TS test suites. The feedback from testing will also suit your TS code (eg. pointing to lines in your TS file instead of unrecognizable compiled JS code). You can't reliably test the compiled JS code because you can't guarantee what gets compiled (eg. symbol names) stays the same between different versions of TS, or tsconfig.json settings. There really isn't any (obvious) benefit to pre-compiling and then testing the compiled code. — user6572277
– user6572277, Commented Dec 4, 2020 at 5:36
Test are usually written in the same language as what they're testing. Consider that the tests will be compiled as well. Make the assumption that the compiler is perfect. — Ouroborus
– Ouroborus, Commented Dec 4, 2020 at 6:05
thanks guys i'm surprised you didn't put it as an answer so that you can get credit for it. — 7wp
– 7wp, Commented Dec 4, 2020 at 7:56
Another good reason to test the TS code (IF your tests themselves are in TS) is that the compilation of any new code is rolled up into the TS code of the test itself (at the time of the test), so you don't have to rebuild your TS into compiled JS explicitly before each test (or forget to do it and rip your hair out wondering why your logic is out of date). — Ciabaros
– Ciabaros, Commented Nov 8, 2024 at 7:00

deerawan · Accepted Answer · 2020-12-09 11:47:32Z

3

I used to test its js compiled code, but then I found that running the test over the Typescript files more makes sense. The main strong reason is for easier debugging if any test is failed because we code and test on the same Typescript file.

Below is an example for debugging a failed test:

⚠️ See the expect line number which has a discrepancy in Typescript and compiled Javascript

test.ts

import { expect } from 'chai';

describe('sum', () => {
  it('should return 3', () => {
    expect(2 + 1).to.equal(2); // line 5
  })
})

and its js compiled

"use strict";
exports.__esModule = true;
var chai_1 = require("chai");
describe('a', function () {
    it('should return a', function () {
        chai_1.expect(2 + 1).to.equal(2); // line 6, different number to its source code
    });
});

Test result over the Typescript file using ts-mocha shows the correct problematic line number for line 5

sum
    1) should return 3


  0 passing (12ms)
  1 failing

  1) sum
       should return 3:

      AssertionError: expected 3 to equal 2
      + expected - actual

      -3
      +2
      
      at Context.<anonymous> (mocha/65152263/a.test.ts:5:22) <--- Match with Typescript source code ✅
      at processImmediate (internal/timers.js:439:21)

Meanwhile, for the js test result, it will give you line number 6. 😫

For a small test file, it might be not too cumbersome to find the issue, but not great if we have many tests.

answered Dec 9, 2020 at 11:47

deerawan

8,5035 gold badges46 silver badges51 bronze badges

Sign up to request clarification or add additional context in comments.

1 Comment

revelt Over a year ago

One possible solution to help locating failing tests is to add a test number, in title and assert message. For example, in tap the unit test runner: tap.test("01 - check number", (t) => { t.equal(1, 2, "01"); t.end(); }); — I wrote eslint rule to automate the maintenance of test numbers, eslint-plugin-test-num — in theory it could be adapted for chai or jest or whatever — for example, see my real prod test github.com/codsen/codsen/blob/main/packages/string-strip-html/… — it works for me

Collectives™ on Stack Overflow

Running tests on Typescript source code Versus the generated JavaScript

1 Answer 1

1 Comment

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

1 Comment

Your Answer

Sign up or log in

Post as a guest

Related