https://netsuiteprofessionals.com logo
Join Slack
Powered by
I am starting to learn some unit testing with jest...
# suitescript
d
I am starting to learn some unit testing with jest in suite cloud, but I dont understand the concept of that testing, for example: Why should i test if setValue for memo is working or record.save is working ? i think i miss something about this concept... i have read all the guides and blogs but still all of the examples there didn't give me too much knowledge... For my developments i do the test in SB account, so what is the advantage for that unit testing?
r
you wouldn't unit test native netsuite methods. You'd unit test your own written functions. Let's say you have a function 
createSpecificSalesOrder(customer, date, items)
that • is provided a customer, date, and items • creates a sales order transaction for that customer, on that date, with those items attached • sets a field on the transaction of "follow-up date" for 30 days from the date provided • returns the newly created sales order IID you'd write your own unit tests that test 
createSpecificSalesOrder()
, and within that unit test, check after the function is completed that • the sales order transaction was created • all proper fields were filled in with expected data (ex, making sure "follow-up date" is exactly <provided date>+30 days
👍 2
c
I would take this a step further and break out your business logic from netsuite logic and only test your business logic. In the case above, I would have a method that calculates a follow up date and would send just the data you need to set into the create transaction function. At that point, you can test how your follow up date is calculated independently of the create transaction. Your test can validate that you called your create transaction method with the data you expect and not whether or not netsuite is working correctly that day. The way i'm reading this, you're testing netsuite as well as some business logic which doesn't need to be done IMO. Its an art form to write tests for sure so there's definitely more than one way to do it.
👍 1
b
the point of tests is to specify how your code should behave
the most basic of which is that given a certain input, your code should produce a certain output
with the example being that if a function is called with certain arguments, it should return a specified value
in rick's case, his inputs are pretty simple, a customer, date, and items
the outputs are more complex, its call record.create with certain parameters, a bunch of set field values with certain parameters, and calling record.save when you are done
along with the more obvious output of a sales order id
if you are being thorough, in your test, you would be calling 
createSpecificSalesOrder
with predefined inputs, mocking the record module calls, and then testing that the record modules was called like you expect with matchers
that can actually be a lot of work, which is why @creece is recommending you refactor your business logic into subfunctions and you only write tests on your business logic
which level of testing depends on how good your test needs to be
if the next person to come around rewrites your code to not use your subfunction, then your test isnt going to do much, but its unlikely that the next person will be able to create a sales order without using the record module
the point of the tests is to make sure the code works a certain way despite any changes that may happen in the future
r
good points. I should've used a tighter example like 
calculateFollowUpDate()
. I'm too used to mocking up things from my previous job. I haven't yet started unit tests myself in NetSuite, although I want to, just don't have the time yet to move to full SDF implementation.
d
Do you have more examples?
61 Views
Open in Slack
PreviousNext
Powered by