feat: expected statements #299
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
use the same naming pattern for the test data
allow the user to configure the mt940/mt920 parsing individually to the custom needs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes are introduced?
Explain the changes you’ve made. It doesn’t need to be fancy and you don’t have to get to technical, yet. At a high level, this is where you let the reviewer know the overall effect of the PR. Reference a ticket from your issue tracker if possible.
Why are these changes introduced?
The “why” tells us what business or engineering goal this change achieves. It’s the reason we get paid as developers. The “why” is a chance to explain both the engineering goal, but also a some business objective that is satisfied or moved along.
How are these changes made?
Of course, the PR diff will tell most of the story of the “how”, but make sure to draw attention to the significant design decisions. You decided to write a recursive method instead of a loop, pointing out the merits of this will help the reviewer understand your reasoning and in turn provide a better review.
How was it tested? (optional)
remove this section, when you don't add further information
Some code, especially infrastructure code (say HELM or Kubernetes yaml files) are harder to test. So it’s important to let the reviewer know how you tested them in case you can’t check in tests. Alternatively, you can explain to the reviewer how to test it locally if necessary. Showing the results of tests you’ve run in this section if none are visible in the diff is also very helpful.
Hints for Reviews? (optional)
remove this section, when you don't attach further hints
Screenshots, Sample Data