npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@ayana/test

v2.1.0

Published

Testing libraries and config for Ayana projects

Downloads

41

Readme

@ayana/test NPM Discord XO code style

Installation

With NPM

npm i @ayana/test typescript --save-dev

With Yarn

yarn add @ayana/test typescript --dev

Basic Usage

  1. Add the following scripts to your package.json:

    {
        "name": "your-project",
        ...
        "scripts": {
    		"test": "ayt test",
    		"cover": "ayt coverage"
        }
    }

    By Ayana convention the code lives in the src directory if it's an application and in the lib directory if it's a library. Files outside of these directories will be ignored.

  2. Exclude .spec.ts files in your tsconfig.json (If you are using ayc from @ayana/ts this step can be skipped):

    {
        ...
        "exclude": [
    	    "./lib/**/*.spec.ts"
        ]
    }
  3. Create .spec.ts files named after the file you want to test next to the file you want to test:

    Say your file lives under lib/hello/Hello.ts, then you would create a file for the tests at lib/hello/Hello.spec.ts.

    import '@ayana/test';
    
    autoDescribe(function() { // autoDescribe will take the path after the lib or src folder and use it as the descriptor
        describe('#constructor', function() {
    	    it('should do a thing', function() {
    
    	    });
        });
    });

    Tests are written with mocha. In addition there's also the global variables sinon and expect (powered by unexpected) available for usage in tests.

Testing with @ayana/di

When using the import @ayana/test/di this package adds another global variable called TestInjector. Using this you can easily write Unit-Tests for components and the TestInjector will automatically create a sinon stub for all required components.

Tested.spec.ts:

import '@ayana/test/di';

import { Tested } from './Tested';

import { SomeDependency } from './SomeDependency';

autoDescribe(function() {
	describe('#doSomething', function() {
		it('should do a thing', function() {
			const injector = TestInjector.test(Tested);
			const tested = injector.getTested();

			tested.doSomething();

			expect(
				injector.getStub(SomeDependency).someMethod.callCount,
				'to be',
				1
			);
		});
	});
});

Tested.ts:

import { Inject } from '@ayana/di';

import { SomeDependency } from './SomeDependency';

export class Tested {
	constructor(@Inject() private someDependency: SomeDependency) {}

	doSomething() {
		this.someDependency.someMethod();
	}
}

SomeDependency.ts:

export class SomeDependency {
	someMethod() {
		console.log('Does Something');
	}
}

Troubleshooting

I'm getting errors because typings could not be found but the regular tsc command works

This might be caused by you having custom .d.ts files in your project. ts-node apperantly resolves custom .d.ts files differently than tsc does.

You can find a way to fix this in the TS-Node README. You want to set the baseUrl and the paths array in the compilerOptions in your tsconfig.json like it's mentioned there.

I'm getting errors about experimental decorator support but I have it enabled in my tsconfig.json

If you get an error like this:

Experimental support for decorators is a feature that is subject to change in a future release. Set the 'experimentalDecorators' option in your 'tsconfig' or 'jsconfig' to remove this warning. ts(1219)

It is because you excluded the .spec.ts in your main tsconfig.json like mentioned above so that config doesn't apply to .spec.ts files anymore. If you need to use decorators in your tests, then you currently have to create a second file for the actual build (tsconfig.prod.json is recommended) and move the exclude property for the .spec.ts files there:

{
	"extends": "./tsconfig.json",
	"exclude": [
		"./lib/**/*.spec.ts"
	]
}

Also you need to update your build command to tsc -p tsconfig.prod.json. Running tsc should work just fine, however the output directory will also contain the compiled files of the tests which you might not want in your npm package or deployed application.