feat: templategen command e2e integration tests #13984
Conversation
| fs.writeFileSync(backendFilePath, updatedBackendFileContent); | ||
| } | ||
|
|
||
| function setEnvVariable(name: string, value: string) { |
| await executeCommand(commands[0], cwd); | ||
| await retry( | ||
| () => assertStepCompletion(commands[1]), | ||
| (status) => status.includes('COMPLETE') && !status.includes('IN_PROGRESS'), |
There was a problem hiding this comment.
nit: move IN_PROGRESS to a constant.
| await retry( | ||
| () => assertStepCompletion(commands[1]), | ||
| (status) => status.includes('COMPLETE') && !status.includes('IN_PROGRESS'), | ||
| { |
There was a problem hiding this comment.
we can also move the retry config object to a constant since its the same across steps.
| ); | ||
| } | ||
|
|
||
| export async function stackRefactor(projRoot: string, category: string, bucketName: string) { |
There was a problem hiding this comment.
nit: make category param a type to constrain the possibilities: export RefactorCategory = 'auth' | 'storage'
|
|
||
| async function executeStep3(cwd: string, commands: string[], bucketName: string) { | ||
| setEnvVariable('BUCKET_NAME', bucketName); | ||
| await executeCommand(commands[1], cwd); |
There was a problem hiding this comment.
can we name the commands instead of accessing by indices for easier understanding: e.g. const [uploadSourceTemplate , uploadDestinationTemplate, ...] = commands ?
There was a problem hiding this comment.
If we follow the Black Box Testing approach, this approach is out of scope then?
| process.env[name] = value; | ||
| } | ||
|
|
||
| function extractContent(readmeContent: string, startRegex: string, endRegex: string) { |
| throw new Error('README file parsing failed to get the stack refactor commands'); | ||
| } | ||
|
|
||
| function extractCommands(readmeContent: string) { |
| return commands; | ||
| } | ||
|
|
||
| function getCommandsFromReadme(readmeContent: string) { |
There was a problem hiding this comment.
I think the README parsing logic is difficult to follow here. Unless a code reviewer knows a logic beforehand, it is not trivial to know what command 1,2,3 are. Some options here:
- Black box : Parse the README and get the list of commands, execute them one by one and doesn't care what it is. the test only cares about the end state of the stacks (i.e stack in UPDATE_COMPLETE) and resources are moved/renamed to the right stacks. (Note: You can use stack state to know if update/refactor operation is completed or not, doesn't have to get refactor object or changeset)
- White-box: parse the README and assume knowledge on the migration logic, like command 1 : upload to s3, command 2: update stack, command 3: refactor, and so on.
const stackMigrationHandler = StackMigrationHandler.fromTemplateGenReadme(<readme path>)
stackMigrationHandler.uploadToS3()
stackMigrationHandler.updateStack()
stackMigrationHandler.refactorStacks()
......
I would suggest the black box testing for simplicity.
There was a problem hiding this comment.
That's a great idea. We can do both kinds of testing based on what we are testing. For the happy path, we can do black box testing since we only care about the end state. We already have getCommandsFromReadme, we can just execute them one by one.
For the rollback scenario, we need to extract Rollback specific commands. So that can be its own test.
There was a problem hiding this comment.
Sounds good, will keep the logic for the getCommandsFromReadme and executing commands one by one logic as it is. Should the commands be stored in a variable or accessing them by indices should be okay for this approach?
There was a problem hiding this comment.
yeah in the black box mode, we don't need the names. Iterating them one by one would suffice.
Description of changes
Added e2e integration test for templategen command which runs as a part of the
yarn e2e-migrationcommandDescription of how you validated changes
Manually checked and verified the deployed stack resources, assertion statements
Checklist
yarn testpassesBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.