{"id":18762238,"url":"https://github.com/veganaize/tdd","last_synced_at":"2026-02-06T10:37:14.104Z","repository":{"id":206102714,"uuid":"715834872","full_name":"veganaize/TDD","owner":"veganaize","description":"Test-Driven Development","archived":false,"fork":false,"pushed_at":"2025-11-03T23:33:41.000Z","size":265,"stargazers_count":7,"open_issues_count":0,"forks_count":1,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-11-04T01:18:06.891Z","etag":null,"topics":["software-engineering","tdd","test","test-automation","test-driven-development","testing"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/veganaize.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2023-11-07T23:35:22.000Z","updated_at":"2025-11-03T23:33:44.000Z","dependencies_parsed_at":"2024-01-11T18:18:14.595Z","dependency_job_id":"da9bbfb4-4c2d-4d88-b5a7-6e15b7536a3c","html_url":"https://github.com/veganaize/TDD","commit_stats":null,"previous_names":["veganaize/tdd"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/veganaize/TDD","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/veganaize%2FTDD","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/veganaize%2FTDD/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/veganaize%2FTDD/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/veganaize%2FTDD/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/veganaize","download_url":"https://codeload.github.com/veganaize/TDD/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/veganaize%2FTDD/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29158103,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-06T07:18:23.844Z","status":"ssl_error","status_checked_at":"2026-02-06T07:13:32.659Z","response_time":59,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["software-engineering","tdd","test","test-automation","test-driven-development","testing"],"created_at":"2024-11-07T18:20:09.901Z","updated_at":"2026-02-06T10:37:14.086Z","avatar_url":"https://github.com/veganaize.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"Test-Driven Development\n=======================\n\n\n\u003cimg src=\"https://avatars.githubusercontent.com/u/46154?v=4\" width=\"32px\"\n/\u003e [Canonical TDD](https://tidyfirst.substack.com/p/canon-tdd) ([Kent Beck](https://en.wikipedia.org/wiki/Kent_Beck))\n------------------\n\n**OBJECTIVES:**\n* Everything that used to work still works.\n* The new behavior works as expected.\n* The system is ready for the next change.\n* The programmer \u0026 their colleagues feel confident in the above points.\n\n**STEPS:**\n1. Write a list of the test scenarios you want to cover.\n2. Turn exactly one item on the list into an actual, concrete, runnable test.\n   - **3A** (Bill Wake):\n     |    |           |                      |\n     |:--:|-----------|----------------------|\n     | 1. | _Arrange_ | Create some objects. |\n     | 2. | _Act_     | Stimulate them.      |\n     | 3. | _Assert_  | Check the results.   |\n     \n4. Change the code to make the test (\u0026 all previous tests) pass (adding items to the list as you discover them).\n5. Optionally refactor to improve the implementation design.\n6. Until the list is empty, go back to #2.\n\n\n\u003ca href=\"https://github.com/unclebob\"\u003e\u003cimg src=\"https://avatars.githubusercontent.com/u/36901?v=4\" width=\"32px\"\n/\u003e\u003c/a\u003e [Three Laws of TDD](http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd) [\u003cimg src=\"https://user-images.githubusercontent.com/7102064/160022421-ed9425eb-6a6b-4849-a090-5a27542b60c3.png\" width=\"16px\" /\u003e](https://youtu.be/qkblc5WRn-U) ([Uncle Bob](https://en.wikipedia.org/wiki/Robert_C._Martin))\n-------------------\n\n* _**Rule 1:**_ You are not allowed to write any production code unless it is to make a failing test pass.\n* _**Rule 2:**_ You are not allowed to write anymore of a unit test than is sufficient to fail; and compilation failures are failures.\n* _**Rule 3:**_ You are not allowed to write anymore production code than is sufficient to pass the one failing unit test.\n\n\n\u003cimg src=\"https://www.wikipedia.org/portal/wikipedia.org/assets/img/Wikipedia-logo-v2.png\" width=\"32px\"\n/\u003e [Development Cycle](https://en.wikipedia.org/wiki/Test-driven_development#Test-driven_development_cycle) (Wikipedia)\n-------------------\n\n01. **Add a small / incremental test** for a new feature by discovering specifications from [user stories](https://en.wikipedia.org/wiki/User_story) / [use cases](https://en.wikipedia.org/wiki/Use_case) / [requirements](https://en.wikipedia.org/wiki/Requirement).\n02. **Run all tests** to verify the new test actually fails, for expected reasons, and that new code is actually needed.\n03. **Write the simplest code that passes the new test** and nothing more, even if it's inelegant or hard coded.\n04. **All tests should now pass** or else revise the new code, until they do, to ensure new code meets test's requirements and doesn't cause [regressions](https://en.wikipedia.org/wiki/Software_regression) (ie. break existing features).\n05. **[Refactor](https://en.wikipedia.org/wiki/Code_refactoring), for readablility / maintainability, while running tests to ensure functionality is preserved**\n    - Move code to where it logically belongs.\n    - Remove [hard-coded](https://en.wikipedia.org/wiki/Hard_coding) test data.\n    - Remove [duplicate code](https://en.wikipedia.org/wiki/Duplicate_code).\n    - Make names [self-documenting](https://en.wikipedia.org/wiki/Self-documenting_code).\n    - Split methods into smaller pieces.\n    - Re-arrange inheritance hierarchies.\n06. **Repeat** cycle for each new piece of functionality.\n\n_*Commit often and undo / revert new code which fails any tests, rather than debugging excessively._\n\n\n\u003ca href=\"https://github.com/jitterted\"\u003e\u003cimg src=\"https://avatars.githubusercontent.com/u/47930468?s=200\u0026v=4\" width=\"32px\"\n/\u003e\u003c/a\u003e [Clarify Goals](https://ted.dev/articles/2021/03/05/clarifying-the-goal-of-behavior-change/) [\u003cimg src=\"https://user-images.githubusercontent.com/7102064/160022421-ed9425eb-6a6b-4849-a090-5a27542b60c3.png\" width=\"16px\" /\u003e](https://youtu.be/P8eRY2c8NFY) ([JitterTed](https://github.com/jitterted))\n---------------\n\n01. What should it do? (verbalize the goal; be clear \u0026 precise)\n02. How will you know it did it? (expected outcome; observable)\n03. Write test for code yet-to-be.\n04. (Fails to compile.)\n05. Write least amount of code to compile.\n06. Predict how test will fail. (precisely)\n07. Run test.\n08. (Fails in predicted way.)\n09. Write least amount of code to pass.\n10. Predict it will pass.\n11. Run test.\n12. (Passes!)\n\n\n🌐 More Info\n------------\n\n* [Dispelling Myths About TDD](https://www.agileinstitute.com/articles/dispelling-myths-about-test-driven-development) - Agile Institute\n* [How to debug small programs](https://ericlippert.com/2014/03/05/how-to-debug-small-programs/) - Eric Lippert\n* [What's in a Story?](https://dannorth.net/whats-in-a-story/) - Dan North\n* [Introducing BDD](https://dannorth.net/introducing-bdd/) - Dan North\n* [Spike Solutions](https://www.jamesshore.com/v2/books/aoad1/spike_solutions) - James Shore\n  - [Spikes in Scrum: The Exception, not the Rule](https://web.archive.org/web/20180712125321id_/https://scrumalliance.org/learn-about-scrum/agile-atlas/agile-atlas-commentaries/may-2014/spikes-in-scrum-the-exception,-not-the-rule) - Scrum Alliance\n* [Structure and Interpretation of Test Cases](https://youtu.be/MWsk1h8pv2Q) - Kevlin Henney (youtube video)\n* [Unit Testing Best Practices](https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices) - Microsoft\n* [Use Cases are Essential](https://dl.acm.org/doi/pdf/10.1145/3631182) - Ivar Jacobson \u0026 Alistair Cockburn\n* [Unit Test](https://martinfowler.com/bliki/UnitTest.html) - Martin Fowler\n* [Integration Test](https://martinfowler.com/bliki/IntegrationTest.html) - Martin Fowler\n* [XP Design Rules](https://martinfowler.com/bliki/BeckDesignRules.html) - Martin Fowler\n* [Test Doubles](https://martinfowler.com/bliki/TestDouble.html) - Martin Fowler\n* [Focus on Branch Logic](https://www.geepawhill.org/2019/02/18/pro-tip-tdd-focus-on-our-branching-logic/) - GeePaw\n* Assertions: [Java](https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html); [Python](https://wiki.python.org/moin/UsingAssertionsEffectively)\n* [Glossary of Software Testing Terms](https://astqb.org/assets/documents/Glossary-of-Software-Testing-Terms-v3.pdf) - ISTQB\n* [Cost of Poor Quality Software](http://web.archive.org/web/20200817233131id_/https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2018-report/The-Cost-of-Poor-Quality-Software-in-the-US-2018-Report.pdf) - CISQ\n* Refactoring to Design Patterns: [preface](https://courses.cs.duke.edu/compsci308/spring24/readings/kerievsky_preface.pdf); [catalog](https://www.industriallogic.com/refactoring-to-patterns/catalog/)\n* [Code Katas](https://sammancoaching.org/kata_descriptions/) - Samman Coaching\n* [Ensemble Programming Guidebook](https://ensembleprogramming.xyz/) - Maaret Pyhäjärvi\n* Diagrams\n  - [UML Quick Reference Card](http://tnerual.eriogerg.free.fr/umlqrc.pdf) - 2001\n  - [Allen Holub’s UML Quick Reference](https://holub.com/uml/) - 2017 _([1998 version](http://cheat-sheets.org/saved-copy/UML%20Reference%20Card.pdf))_\n  - [UML Class and Sequence Diagram Cheatsheet](https://loufranco.com/wp-content/uploads/2023/06/uml-cheatsheat-class-sequence-letter.pdf) - 2023\n  - [UML v2.5.1 Spec](https://www.omg.org/spec/UML/2.5.1/PDF) - 2017\n  - [UML](https://en.wikipedia.org/wiki/Unified_Modeling_Language) - wikipedia\n  - [Class Diagram](https://en.wikipedia.org/wiki/Class_diagram) - wikipedia\n  - [C4](https://c4model.com/)\n* Wikipedia\n  - [Acceptance Testing](https://en.wikipedia.org/wiki/Acceptance_testing)\n  - [Anti-Pattern](https://en.wikipedia.org/wiki/Anti-pattern)\n  - [Extreme Programminng](https://en.wikipedia.org/wiki/Extreme_programming)\n    - [extremeprogramming.org](http://www.extremeprogramming.org/) \u003cimg src=\"http://www.extremeprogramming.org/images/xplinksm.gif\" width=\"29px\" /\u003e\n  - [Functional Testing](https://en.wikipedia.org/wiki/Functional_testing)\n  - [Fuzz Testing](https://en.wikipedia.org/wiki/Fuzzing)\n  - [Integration Testing](https://en.wikipedia.org/wiki/Integration_testing)\n  - [Side Effect](https://en.wikipedia.org/wiki/Side_effect_(computer_science))\n  - [Usability Testing](https://en.wikipedia.org/wiki/Usability_testing)\n* [Scrum Guide](https://scrumguides.org/) (official)\n  - [Scrum Guide Revision History](https://scrumguides.org/revisions.html) (official)\n  - [Changed Words in Scrum Guide 2020](https://www.scrum.org/resources/blog/words-changed-scrum-guide-2020-update)\n  - [Removed Words in Scrum Guide 2020](https://www.scrum.org/resources/blog/scrum-guide-2020-update-what-has-been-removed)\n  - [2017 Scrum Guide](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf) (official) (old)\n  - [2016 Scrum Guide](https://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf) (official) (old)\n\n\n:octocat: Version Control\n-------------------------\n\n[Git](https://git-scm.com/docs/gittutorial); [Signing Your Work](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work); [Better Commit Messages](https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/); [Git Aliases](https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases)  \n[Github Flow](https://docs.github.com/en/get-started/using-github/github-flow); [Gitflow - Vincent Driessen's branching model](https://nvie.com/posts/a-successful-git-branching-model/)  \n[Github Markdown](https://docs.github.com/en/get-started/writing-on-github); [Stackoverflow Markdown](https://stackoverflow.com/editing-help); [Github Task Lists](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists); [Google Markdown Style Guide](https://google.github.io/styleguide/docguide/style.html)\n\u003cpre\u003e\ngit [command] -h      # Help in console\ngit \u0026lt;command\u003e --help  # As man page (Linux); in browser (Windows)\ngit help \u0026lt;command\u003e    # As man page (Linux); in browser (Windows)\ngit init .\ngit add .\ngit add -u  # stage tracked (modified \u0026 deleted) files only\ngit status\ngit commit -m \"Commit message\"\ngit log [--oneline] [--author=name]\ngit tag 1.0.0 \u0026lt;commit-id-from-log\u003e\n\ngit restore --staged \u0026lt;file\u003e\ngit restore \u0026lt;file\u003e\ngit reset --hard\n\ngit \u003ca href=\"https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning\"\u003estash\u003c/a\u003e [-u | --include-untracked] [-m \"Stash message\"]\ngit stash list\ngit stash branch \u0026lt;new_branchname\u003e\ngit stash pop\n\ngit worktree add ../hotfix [new-branch]\ncd ../hotfix\ngit worktree list\ngit worktree remove \u0026lt;path\u003e [--force]  # Doesn't delete worktree branch\n\ngit checkout -b \u0026lt;new_feature_branch_name\u003e\ngit diff [--cached]\ngit checkout \u0026lt;master | main\u003e\ngit branch  # List branches; Highlight current\ngit merge --squash \u0026lt;new_feature_branch_name\u003e\ngit branch [-d | --delete | -D] \u0026lt;new_feature_branch_name\u003e\n\ngit clone [--no-single-branch] git@github.com:veganaiZe/TDD.git\ngit clone [--depth=50] https://github.com/veganaiZe/TDD.git\ngit \u003ca href=\"https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes\"\u003eremote\u003c/a\u003e add origin \u0026lt;original_upsteam_repo_server\u003e\ngit pull --rebase\ngit push\n\u003c/pre\u003e\n\n\n💡 Principles\n-------------\n\n* Constantly check/consider code against design principles:\n  - [KISS](https://en.wikipedia.org/wiki/KISS_principle): ***keep it short \u0026 simple***; do the simplest thing that could possibly work, first.\n  - [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself): ***don't repeat yourself*** (more than a very few times -- ie. ***get WET first!***).\n  - [POLA](https://en.wikipedia.org/wiki/Principle_of_least_astonishment): ***principle of least astonishment*** --measured by f-words per minute.\n  - [YAGNI](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it): ***you ain't gonna need it***.\n  - ***\"Never let perfect be the enemy of good enough.\" (for now)***\n  - ***\"As little as possible; As much as necessary.\"***\n  - [SOLID](https://en.wikipedia.org/wiki/SOLID):\n    - [SRP](https://en.wikipedia.org/wiki/Single-responsibility_principle): single responsibility principle; ***do one thing well.***\n    - [OCP](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle): open-closed principle; ***extend, don't modify.***\n    - [LSP](https://en.wikipedia.org/wiki/Liskov_substitution_principle): liskov substitution principle; ***subtype like basetype.***\n    - [ISP](https://en.wikipedia.org/wiki/Interface_segregation_principle): interface segregation principle; ***granular interfaces.***\n    - [DIP](https://en.wikipedia.org/wiki/Dependency_inversion_principle): dependency inversion principle; ***inject dependencies.***\n\n\n\u003cimg src=\"https://github.com/user-attachments/assets/20044412-0611-4bb9-ad6f-8c50435753e3\" width=\"32px\"\n/\u003e veganaiZe's TDD Steps\n------------------------\n\n1. Determine the next __*DESIRED METHOD*__ (ie. interface): from the perspective of the __*APPLICATION CODE*__.\n2. Create a new development branch, and switch to it: `git checkout -b new-branch-name`\n3. Write just enough __*TEST CODE*__, for the desired interface (in \"Act\" section), to observe the __*TEST FAILING*__ against the application's missing interface code.\n4. Write just enough __*APPLICATION CODE*__, implementing an empty method (returning the correct type), to observe the __*TEST PASSING*__ against the application's *incorrect* return value.\n5. Write just enough __*TEST CODE*__, including an error detail message (in \"Assert\" section), to observe the runtime __*ASSERTION FAILING*__ as expected against the application's incorrect return value.\n6. Write just enough __*APPLICATION CODE*__, to observe the runtime __*ASSERTION PASSING*__, by correcting the return value; first iteration being hard-coded.\n7. Refactor __*APPLICATION CODE*__ to improve __*OBVIOUS WEAKNESSES*__, repeating steps 5 \u0026 6 to suss out \u0026 correct issues, as necessary. (ie. remove duplicate / hard code)\n8. Commit the small \u0026 focused change into the upstream branch/repo:\n    ```\n    git checkout master\n    git merge --squash new-branch-name\n    git commit -m \"Commit message ...\"\n    git branch -D new-branch-name\n    ```\n\n\n✏️ Personal Notes\n-----------------\n\n* When on the fence over whether or not to put some code into its own method: do it, especially if it has any (branch) logic in it.  And TDD it into existence!\n* When on the fence over whether or not to pre-process data, or process it at runtime, spike/tdd the common functionality before deciding.\n* The `main` function is not TDDed; The application's `main` code is replaced by the unit tests' `main` code, and vice versa; The application's `main` code is tested at the user interface level (top) of the [test pyramid](https://en.wikipedia.org/wiki/Test_automation#Testing_at_different_levels).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fveganaize%2Ftdd","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fveganaize%2Ftdd","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fveganaize%2Ftdd/lists"}