TDD Kata

tdd-kata

Calculator : Add feature. Work in pairs. The implementer is lazy and writes ugly code. Tester forces generalized solution and is the designer of the API. Can the tester force internal quality of the code?

The Rules :

Keith Braithwaite’s rules to force the pair to allow the design to evolve:

1.	Write exactly one new test, the smallest test you can that seems to point in the direction of a solution
2.	See it fail
3.	Make the test from (1) pass by writing the least implementation code you can in the test method. 
4.	Refactor to remove duplication, and otherwise as required to improve the design. Be strict about using these moves:
	1.	you want a new method—wait until refactoring time, then… create new (non-test) methods by doing one of these, and in no other way:
	a)	preferred: do Extract Method on implementation code created as per (3) to create a new method in the test class, or
	b)	if you must: move implementation code as per (3) into an existing implementation method
	2.	you want a new class—wait until refactoring time, then… create non-test classes to provide a destination for a Move Method and for no other reason
	a)	populate implementation classes with methods by doing Move Method, and no other way
The member of the pair without their hands on the keyboard must be very strict in enforcing these rules, especially 4.1 and 4.2

Practice #1

TDD Kata- an exercise in coding, refactoring and test-first, that you should apply daily for at least 15 minutes.

	▪	Try not to read ahead.
	▪	Do one task at a time. The trick is to learn to work incrementally.
	▪	Make sure you only test for correct inputs. There is no need to test for invalid inputs for this kata.
 
String Calculator
1.	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
2.	Allow the Add method to handle an unknown amount of numbers
3.	Allow the Add method to handle new lines between numbers (instead of commas).
	1.	the following input is ok:  “1\n2,3”  (will equal 6)
	2.	the following input is NOT ok:  “1,\n” (not need to prove it - just clarifying)
	1.	Support different delimiters
	2.	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 ‘;’ .
	3.	the first line is optional. all existing scenarios should still be supported
4.	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.
Stop here if you are a beginner. Continue if you can finish the steps so far in less than 30 minutes.
5.	Numbers bigger than 1000 should be ignored, so adding 2 + 1001  = 2
6.	Delimiters can be of any length with the following format:  “//[delimiter]\n” for example: “//[***]\n1***2***3” should return 6
7.	Allow multiple delimiters like this:  “//[delim1][delim2]\n” for example “//[*][%]\n1*2%3” should return 6.
8.	make sure you can also handle multiple delimiters with length longer than one char