The document discusses Test Driven Development (TDD) and Code Dojo, an exercise where programmers work together on coding problems while learning. It describes the basics of TDD using the example of creating a String calculator, including writing tests first and refactoring code between each passing test. The document outlines expanding the calculator to handle various scenarios like multiple numbers, delimiters, exceptions for negatives, and ignoring numbers over 1000.
Short Story: Unveiling the Reasoning Abilities of Large Language Models by Ke...
Introduction to TDD
1. Women Who Can Code
Code Dojo : Basics of Test Driven Development
11th March 2015
Laavanya Kathiresen @Nintex
2. What is Code Dojo ?
Programmers gather to train & learn, working together on a problem (while having
fun!)
NOT a competition
2 types of ways of running it :
● Prepared Kata (with Baby Steps)
● Randori Kata
3. Test Driven Development (TDD)
Kent Beck - Father of TDD
Test First Programming Concept
Repetition of short development cycle
Red-Green-Refactoring
Having unit tests doesn’t mean
you’ve done TDD
4. Why do TDD ?
Better code quality (less coupling)
Encourages simple design and concepts
Reduces the risk of over-engineering
Ability to refactor without fear of ‘breaking’ anything
Improved maintainability and changeability of the codebase
& MANY MORE!!!!
7. Create a simple String calculator with a method int Add(string
numbers)
1. The method can take 0, 1 or 2 numbers, and will return their sum (for an empty string it will return 0) for
example “” or “1” or “1,2”
2. Start with the simplest test case of an empty string and move to 1 and two numbers
3. Remember to solve things as simply as possible so that you force yourself to write tests you did not think about
4. Remember to refactor after each passing test
8. Allow the Add method to handle an unknown amount of
numbers
9. Allow the Add method to handle new lines between numbers
(instead of commas).
1. the following input is ok: “1n2,3” (will equal 6)
2. the following input is NOT ok: “1,n” (not need to prove it - just clarifying)
10. Support different delimiters
1. to change a delimiter, the beginning of the string will contain a separate
line that looks like this: “//[delimiter]n[numbers…]” for example
“//;n1;2” should return three where the default delimiter is ‘;’ .
2. the first line is optional. all existing scenarios should still be supported
11. Calling Add with a negative number will throw an exception
“negatives not allowed” - and the negative that was passed.
If there are multiple negatives, show all of them in the
exception message
13. Delimiters can be of any length with the following format:
“//[delimiter]n” for example: “//[***]n1***2***3” should
return 6
14. Challenges in TDD…..
Initially it might take longer than expected to do TDD
… hence might not get the support and encouragement from management
Developers tend to ‘reverse-engineer’ unit test hence losing the benefit of TDD
TDD on legacy code can be challenging
15. Puts “That’s it for now, thank you for
participatingn”
Puts “Please do give you feedback on what
you’ll to know more on”
16. Allow multiple delimiters like this: “//[delim1][delim2]n”
Example “//[*][%]n1*2%3” should return 6.