-
Notifications
You must be signed in to change notification settings - Fork 79
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
refactor(data_dir): simplify logic and make code robust and testable #880
base: develop
Are you sure you want to change the base?
Conversation
@pano9000 , I think method A is a bit verbose for the JavaScript world. |
thanks for the reply, I don't like method B) either to be honest, so method C) would be a good middle end, but it might require additional dev Dependencies. Currently I can see I am almost inclined to do method A) locally (without commiting) to run all tests and gather confidence that everything works as expected, and then push out this test into a separate PR – depending on which test runner framework the decision falls on. (with some manual tests I did locally everything seems to have been working properly already). |
gets rid of previously "magic number"
removes some code duplication
- the blocks now clearly follow the intended logic described in the comments - I renamed the `getAppDataDir` to more specific `getPlatformAppDataDir`
previously exported object allowed the values to be changed accidentally at runtime and buildtime
makes it a bit cleaner and easier to test in the future, as it is one thing less that'd need mocking :-)
74b6fa4
to
d492ea0
Compare
I've pushed aside the DI idea above and am working on your suggested method C) straight away now – I am doing it with the built-in node:test features for now locally – once the test logic / cases are defined, we can easily adapt them to whatever test runner framework |
@eliandoran I've written a full test that confirms all different cases are working as expected. so not sure, if I should even commit that test or not? you can run it, using the following (of course adjust the path accordingly):
|
Hi,
this PR aims to refactor the
data_dir.ts
file.getTriliumDataDir
function to be more easy to follow the order of "trilium data path order of priority"regarding the
getTriliumDataDir
tests:since this function is also using
fs
related methods (i.e. checking for folder existance and folder creation), I have to ways on how to make the function testable:a) using a simple DI object, to "inject" these dependencies (
fs
methods, etc.) which will allow to mock these functions in the tests, e.g. like so:in the tests, these would be swapped out by mocks, in the "production" code these are just using the real methods by default.
b) using the real methods and then having to make sure folders are cleaned up afterwards
I personally would prefer a) however I did not see this technique being used in the repo so far, so would like to have an OK before I go that route?
@eliandoran what do you think?