Question: Unit testing with xplat + nativescript?

[m-abs]

Hi @NathanWalker

How would you do unit testing for nativescript with xplat?

The shared code and web is easy enough with ng test, but I'm not sure what is the best strategy for nativescript.

Would it be best to generate a nativescript-test app and configure it with tns test init or is there a better way to do it?

I see nativescript-angular uses their own wrappers for TestBed: https://github.com/NativeScript/nativescript-angular/blob/master/tests/app/tests/list-view-tests.ts

Maybe the generated spec-files for xplat/nativescript should use these?

[m-abs]

I've been looking into this with the intend to create a PR once it's done.

But I've run into a (minor?) problem. tns test doesn't like the typescript-path mappings, so it cannot find @prefix/core, @prefix/features etc. at runtime. Is there a reason there isn't a package.json under those? Our project have them but I can't remember if we added them or they were created by an earlier version of @xplat/schematics.

Here is what I've done so far:

• created a new project with create-xplat-workspace
• created a nativescript-app with ng g app.nativescript base
• Executed cd apps/nativescript-base && tns test init (chose jasmine)
• added the file apps/nativescript-base/app/tests/test-main.ts
• added a feature named hugo with the default component.
• added a spec-file for the HugoComponent

apps/nativescript-base/app/tests/test-main.ts

import "nativescript-angular/zone-js/testing.jasmine";
import {nsTestBedInit} from "nativescript-angular/testing";
nsTestBedInit();

import '@prefix/nativescript/features/hugo/components/hugo/hugo.component.spec';

This fails because the runtime can't @prefix/features under tns_modules.

@NathanWalker I'm think about added test-only app under testing/nativescript and have the component generator for nativescript import the spec-files in a script in that app. Do you agree?

[NathanWalker]

@m-abs this is great, I've long thought about this. Ideally I'd prefer to not use {N} test runner but rather standard unit test runners out there however that's not possible today. Generally I'd say we could add package.json for the shared code in order to satisfy this requirement since the packages are just ignored otherwise and wouldn't cause an issue. You're approaching it from the angle that I've often thought might be the best way.

Using testing/nativescript would be a great place to grow out the reusable bits of the setup and provide more and more things that are helpful for the testing setup there.