-
Notifications
You must be signed in to change notification settings - Fork 11
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
fix(cli): fix json format handling #360
Conversation
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 do not understand the changes being made to the tests. They often reintroduce the bad practices again or test logic in the wrong place (cli and core are after test refactor). I provided context in the comments below.
packages/cli/src/lib/implementation/config-middleware.integration.test.ts
Outdated
Show resolved
Hide resolved
const cli = (options = {}) => | ||
yargsCli( | ||
objectToCliArgs({ | ||
_: 'autorun', | ||
verbose: true, | ||
config: '/test/code-pushup.config.ts', | ||
'persist.outputDir': '/test', | ||
...options, | ||
}), | ||
{ | ||
...DEFAULT_CLI_CONFIGURATION, | ||
commands: [yargsAutorunCommandObject()], | ||
}, | ||
); | ||
|
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.
This was removed on purpose for better readability of the tests. By having explicit values present, it is clear which arguments are passed to the test without having to scroll up and look at additional function definitions.
const cli = (options = {}) => | |
yargsCli( | |
objectToCliArgs({ | |
_: 'autorun', | |
verbose: true, | |
config: '/test/code-pushup.config.ts', | |
'persist.outputDir': '/test', | |
...options, | |
}), | |
{ | |
...DEFAULT_CLI_CONFIGURATION, | |
commands: [yargsAutorunCommandObject()], | |
}, | |
); |
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.
they are always the same
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.
It's not a huge issue, but a recurring problem, so maybe it helps to explain the motivation better.
In general, it's better when a test contains all the context you need to know regarding what inputs are provided. Extracting setup code goes against this principle. There's a balance to be struck, of course, e.g. when the setup is long and often repeated in different tests, then extracting it may be the better option.
The old version of this test is more understandable for me, because within the it
-block I see everything I need to understand it - e.g. "Why do the assertions expect /test/code-pushup.config.ts
? Ah yes, because that's what argument was passed in, I see that a few lines above.". But with the new version, the relevant inputs and outputs aren't colocated, so I have to scroll up to understand the whole picture.
In fact, the new cli
function is only used in this one test, so there's no advantage with regards to reducing duplication. And I also don't understand why persist.filename
is specified here, but e.g. persist.outputDir
or config
aren't, they seem to be just as relevant to the assertions.
Co-authored-by: Kateřina Pilátová <katerina.pilatova@flowup.cz>
Co-authored-by: Kateřina Pilátová <katerina.pilatova@flowup.cz>
Co-authored-by: Kateřina Pilátová <katerina.pilatova@flowup.cz>
Co-authored-by: Kateřina Pilátová <katerina.pilatova@flowup.cz>
@@ -78,8 +78,7 @@ describe('CLI collect', () => { | |||
expect(stderr).toBe(''); | |||
|
|||
expect(stdout).toContain('Code PushUp Report'); | |||
expect(stdout).toContain('Generated reports'); | |||
expect(stdout).toContain('report.json'); | |||
expect(stdout).not.toContain('Generated reports'); |
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.
This test scenario runs with --persist.format=stdout
, that should be removed (no longer a valid option). And then I believe the assertions should stay the same, because JSON should be generated by default.
format: [ | ||
...new Set([...options.persist.format, 'json']), | ||
] as AutorunOptions['persist']['format'], |
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.
format: [ | |
...new Set([...options.persist.format, 'json']), | |
] as AutorunOptions['persist']['format'], | |
format: [ | |
...new Set([...options.persist.format, 'json'] satisfies Format[]), | |
], |
or:
format: [ | |
...new Set([...options.persist.format, 'json']), | |
] as AutorunOptions['persist']['format'], | |
format: [...new Set([...options.persist.format, 'json' as const])], |
const cli = (options = {}) => | ||
yargsCli( | ||
objectToCliArgs({ | ||
_: 'autorun', | ||
verbose: true, | ||
config: '/test/code-pushup.config.ts', | ||
'persist.outputDir': '/test', | ||
...options, | ||
}), | ||
{ | ||
...DEFAULT_CLI_CONFIGURATION, | ||
commands: [yargsAutorunCommandObject()], | ||
}, | ||
); | ||
|
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.
It's not a huge issue, but a recurring problem, so maybe it helps to explain the motivation better.
In general, it's better when a test contains all the context you need to know regarding what inputs are provided. Extracting setup code goes against this principle. There's a balance to be struck, of course, e.g. when the setup is long and often repeated in different tests, then extracting it may be the better option.
The old version of this test is more understandable for me, because within the it
-block I see everything I need to understand it - e.g. "Why do the assertions expect /test/code-pushup.config.ts
? Ah yes, because that's what argument was passed in, I see that a few lines above.". But with the new version, the relevant inputs and outputs aren't colocated, so I have to scroll up to understand the whole picture.
In fact, the new cli
function is only used in this one test, so there's no advantage with regards to reducing duplication. And I also don't understand why persist.filename
is specified here, but e.g. persist.outputDir
or config
aren't, they seem to be just as relevant to the assertions.
I added more infos to the issue: #316 also #358 should go before
This PR includes:
Overview of the target architecture can be found here: https://github.com/code-pushup/cli/wiki/Research:-Module-architecture-and-responsibilities
closes #316