basically extract the JS w/ no netsuite code and run unit tests against it.. whether or not netsuite's methods are working isn't something you should test

Creece, the actual netsuite method calls would be beneficial for, and this happens often, someone creates a required field. Integration runs, doesn't set the field, and breaks

I used to use jasmine/karma or mocha/chai/sinon for our NS unit tests but have recently started using jest instead. It's a single package that gives me what used to take several packages.

For example, say you have a function A() that just adds two numbers, and doesn't depend on any NS APIs or anything else. Tests of function A() would all be unit tests

Say you have a function B() which does stuff of its own AND calls something like record.load(). A unit test means trying to only verify behavior of your code in B(), not verifying that NS record.load() works.

Hence, a unit test of B() would require a mock

record.load()

to be deemed a unit test.

if you test B() without mocking

record.load()

then you have an integration test, because this invokes not only the code you wrote in B() but also invokes NS's

record.load()

code.

Hope that all makes some sense.

Also, here one can say

B() depends upon record.load()

or "N/record is a dependency of function B()"

there's always reason to test but there's only a reason to test YOUR business logic. You shouldn't be testing netsuite is what I am saying

well definitely not any coverage to speak of on the js side... maybe the java side has some

i'd only really write tests for critical business logic honestly. You have to write code in a different way in order to do unit testing for a lot of things. If you're testing sublist test for example, you'd have to get all of your line data in a native JS data structure and pass that to a method that does the business logic so you can test that way.. so you've decoupled the netsuite side from the business logic and you can easily test

so that removes the need for some NS interaction and allows a broader range of pure unit tests to be trivially crafted. However often it makes sense to call other NS apis even when you have NSDAL objects.

NFT itself doesn't have the luxury of this abstraction layer (because it IS the abstraction layer) so here is a small example of unit tests for NFT which have to mock the underlying NS apis: https://github.com/ExploreConsulting/netsuite-fasttrack-toolkit-ss2/blob/a989fcf243089cb90d601ed2fe09d5f908fdeb6d/test/nsdal.test.ts

I've just started playing with jest here, and I'm impressed with their easy implementation for mocking and how it is trying to embrace the JS module system to pull in mocks

having done a lot of NS api mocking in the SS1.0 days, my initial experience with jest has been refreshing.

sorry,that was jest config.. yes that's so that jest finds the mocks when code asks for "N/..."

NFT for SS1 unit tests rely on karma and running in the browser. That works but am trying to drop need for browsers for NFT-SS2

client script unit tests may need a browser, but don't need it for server scripts (which is the vast majority of scripting I do)

but no netsuite mocking

no unit tests should need a browser if you use a node based testing framework

One of the challenges I ran into with doing pure node based tests is node uses commonjs modules and NS AMD

that's one spot where TS swoops in to save the day - it outputs commonjs for unit testing purposes while uses AMD for the normal NS build

thats interesting

it helped me go from too-long-without-any-tests-for-NFT-SS2 to having at least a tiny few!

Most likely 99% of netsuite code does not

but I agree, I think it's only a tiny percentage of NS code that has unit tests overall

in the case of NFT it worries me more because it's library code for reuse, so the benefit to unit testing is amplified.