0

As a part of a project I am building I currently have an angular/cli typescript project I have created. We are currently using the karma testing framework, but are extremely interested in switching to AVA if possible.

I've currently done a npm install --save-dev ava And I've looked at the typescript setup in the ava documentation https://github.com/avajs/ava/blob/master/docs/recipes/typescript.md

I've also followed the setup on the main page itself and added an "ava" section to my package.json

"ava": {
  "files": [
    "**/*.spec.ts"
  ],
  "source": [
    "**/*.ts"
  ],
  "match": [],
  "concurrency": 5,
  "failFast": true,
  "failWithoutAssertions": false,
  "tap": true,
  "powerAssert": false,
  "require": [
    "babel-register"
  ],
  "babel": "inherit"
}

I've hoped that somehow by default this would pick up our currently written spec.ts files that have been tailored and written for karma, but it would seem that this isn't so as I'm only given

# Couldn't find any files to test
not ok 1 - Couldn't find any files to test

1..0
# tests 0
# pass 0
# fail 1

I've also tried obliterating the default test.ts file that is currently put in place by Karma and changing it to

import test from 'ava';
test('BLA', t => {
  t.pass();
});

In the hopes that I could at least bootstrap something to work with that I could maybe use to add/implement the rest of our test files with later. So far I've had no luck with this either.

Can someone who has taken this path before tell me what needs to be done to get the Ava test runner up and working; and furthermore, what may need to be done to adapt our currently existing karma/jasmine based test framework to Ava?

Thank you very much in advance!

Slushba132
  • 423
  • 2
  • 5
  • 20

2 Answers2

2

I ran into this answer while searching for something else, and realized it might be worth chiming in, even though it's been a bit since the question was asked.

There is a path to run AVA + TS via ts-node. Additionally, there's a tsconfig-paths package that aids in correctly mapping to tsconfig's paths property, if being used.

Below is what the AVA config would roughly look like. Of course, your paths may be different based on your Angular CLI project structure, but the same basic principles apply:

"ava": {
  "compileEnhancements": false,
  "extensions": [
    "ts"
  ],
  "require": [
    "ts-node/register",
    "tsconfig-paths/register"
  ],
  "files": [
    "src/**/*.spec.ts"
  ],
  "sources": [
    "src/**/*.ts",
    "src/index.ts"
  ],
  "failWithoutAssertions": true
}

Additionally, you may have a testing-specific tsconfig, in which case you'd need to point to it via a TS_NODE_PROJECT environment variable that ts-node will pick up on. So, for example, you're test task might look like this:

TS_NODE_PROJECT=tsconfig-spec.json node_modules/.bin/ava --verbose

Note that because Node natively consumes only CommonJS (at least at the time of this writing), your tsconfig will need to compile to that module format. So, continuing the example above, your tsconfig-spec.json might look like this, among other desired options:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "module": "commonjs",
    "target": "es2015",
    "sourceMap": true
  }
}

The API between AVA and Jasmine is not the same, but it's actually, in my experience, similar enough that the conversion isn't too painful—mostly mechanical. At the time of this writing, there's an issue open to create a codemod for the conversion; however, it looks like it hasn't had much traction yet.

emarticor
  • 350
  • 3
  • 7
1

AVA currently only supports test files with a .js extension. You should precompile your TypeScript test files and change the files pattern to match the tests inside your build directory.

Mark Wubben
  • 3,329
  • 1
  • 19
  • 16
  • 1
    Is there seriously no other way to do this without a pre-processor that converts the files? A few of the open issues on the AVA project seem to suggest that there are ways to do this where this isn't necessary. – Slushba132 Aug 12 '17 at 22:35
  • 1
    There's a lot of people saying it should be easy for their use case, which is correct, but that makes other use cases more difficult. Hence no, currently there is no other way to do this. There's a plan, but there's only so many OSS-hours in a week. – Mark Wubben Aug 14 '17 at 07:46