Skip to content

Instantly share code, notes, and snippets.

@rondy

rondy/git_categories.md

Last active June 27, 2023 17:33
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save rondy/ddccd101058fdf6f542e to your computer and use it in GitHub Desktop.
Save rondy/ddccd101058fdf6f542e to your computer and use it in GitHub Desktop.
Download ZIP
Categorizing git commit messages
Raw
git_categories.md

https://medium.com/@rondy/66df167c7d54

Categorizing git commits and how it affects the test suite

  • If the applied change is a "feature creation" or a "feature evolution" (i.e., it changes the current system behavior), then:
    • It should include a system/acceptance test, or, in case it already exists, ensure that the test will reflect the change.
    • It can optionally include a unit test case, since not every change requires a unit test.
    • A "feature creation" will probably include a good amount of system test and a few of unit tests.
      • Lots of unit test might be a design smell.
    • A "feature evolution" (i.e., changing a feature that already exists) will probably include just enough system test and a good amount of unit tests.
      • Lots of system test might be a design smell.
  • If the applied change is a refactoring, then:
    • it should not include a new test case, since refactoring does not change system behavior, only code structure.
  • If the applied change is a casual fix / chore / annotation, then:
    • it shoud not include a test case, unless it changes the system behavior (i.g., you're fixing a bug).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment