@irurzo I use mocha.js for my unit testing

When is coming the first video about Unit Testing?

Were I still able to produce the videos, that one would still be a ways down the list 🙂

What do you do about netsuite dependencies in your scripts? Or do you just test pure javascript functions? E.g. if your function accepts a record (returned from

record.load

) and manipulates it in some way, how could you test that?

Personally I only test pure JS functions as I don't feel it's my job to test that NS APIs are working. I tend to architect my code in a way that isolates any NetSuite API calls from actual business logic. I usually have functions that translate data from a NS object (say a

Record

instance) into a native JS object, perform my actual business logic on the JS object, then translate that back into the relevant NS object. I only unit test that middle layer that's performing the business logic on JS objects

🤔 That makes sense, thanks. I have written a lot of functions that make somewhat complicated manipulations to records depending on a lot of input parameters, and while I don't want to test if record

record.setValue

worked, I have wished I could unit test that I set the right fields with the right values.

Yeah, I think you have to draw your lines somewhere, and those lines will vary by team. Some people will go so far as to mock all the NS APIs. I choose not to.

The API surface of the the main modules (record and search) is too big to mock IMO. I like your approach of adding a layer of abstraction which frees your (the programmer's) concerns from "NetSuite world", testing at that layer, and then mapping back.