-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce unit tests #7
Conversation
Will allow for better "testability" of the script
The script will be available on PATH if installed globally
Confirmation routines are provided as a module object Will allow for better "testability"
Using node:util for colorized output
They incapculate "knowledge" about the script output files
Renamed setup function to avoid confusion
This led to awkward "double numbering" if sections are added "in the middle"
Expanded commends for invocation example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added few suggestions/questions in line.
A more general comment on the folder structure, I personally think that it looks cleaner to have all the tests under one folder (rather that with the source files). I realise it can come down to personal choice but there are a few reasons I think we should separate them out:
- It separates out the core code from the tests files which makes it easier IMO for people to understand the roles of the individual files
- It helps if you need to run a subset of tests, for example if the different test types are in subfolders of a root test folder, you can use
jest test/*/*
for all tests, andjest test/unit/*
orjest test/integration/*
for unit or full e2e tests. - This is the same approach that the Cloudinary JS SDK follows so would be more consistent across our code bases
RE:
I don't think it makes sense to mimic the setup of the SDK (we already use different testing framework jest vs mocha in SDK). My reasoning has been:
This doesn't seem to be essential aspect of the implementation so I prefer moving faster vs getting things exactly right. Appreciate all your time and the feedback! 🤘 Cheers! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Implemented modifications to allow unit testing and end-to-end testing of the script functionality.