Scribd
Upload
113 views

Test Driven Development

TDD involves writing tests before writing functional code. The process is: 1. Write a test that fails initially due to lack of code 2. Write the minimum amount of code to make the test pass 3. Refactor the code as needed The benefits of TDD include driving the design through incremental changes, catching errors early, and facilitating refactoring through automated testing. TDD was demonstrated through building a String Calculator incrementally based on passing tests.

Uploaded by

ashu sanghavi
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
113 views

Test Driven Development

TDD involves writing tests before writing functional code. The process is: 1. Write a test that fails initially due to lack of code 2. Write the minimum amount of code to make the test pass 3. Refactor the code as needed The benefits of TDD include driving the design through incremental changes, catching errors early, and facilitating refactoring through automated testing. TDD was demonstrated through building a String Calculator incrementally based on passing tests.

Uploaded by

ashu sanghavi
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

NAME: ASHU SANGHAVI SAP ID: 60004168019

Experiment No. 11

Aim: To study Test Driven Development for a sample scenario.

Theory:

TDD – Test Driven Development:

The first step is to quickly add a test, basically just enough code to fail. Next you run your
tests, often the complete test suite although for sake of speed you may decide to run only a
subset, to ensure that the new test does in fact fail. You then update your functional code to
make it pass the new tests. The fourth step is to run your tests again. If they fail you need to
update your functional code and retest. Once the tests pass the next step is to start over (you
may first need to refactor any duplication out of your design as needed, turning TFD into
TDD)

Instead of writing functional code first and then your


testing code as an afterthought, if you write it at all,
you instead write your test code before your
functional code. Furthermore, you do so in very
small steps – one test and a small bit of
corresponding functional code at a time. A
programmer taking a TDD approach refuses to write
a new function until there is first a test that fails
because that function isn’t present. In fact, they
refuse to add even a single line of code until a test
exists for it. Once the test is in place they then do the
work required to ensure that the test suite now passes
(your new code may break several existing tests as
well as the new one). This sounds simple in
principle, but when you are first learning to take a
TDD approach it proves require great discipline
because it is easy to “slip” and write functional code
without first writing a new test. One of the
advantages of pair programming is that your pair
There are two levels of TDD:
helps you to stay on track.
1. Acceptance TDD (ATDD). With ATDD you write a single acceptance test, or
behavioral specification depending on your preferred terminology, and then just
enough production functionality/code to fulfill that test. The goal of ATDD is to
specify detailed, executable requirements for your solution on a just in time (JIT)
basis. ATDD is also called Behavior Driven Development (BDD).
2. Developer TDD. With developer TDD you write a single developer test, sometimes
inaccurately referred to as a unit test, and then just enough production code to fulfill
that test. The goal of developer TDD is to specify a detailed, executable design for
your solution on a JIT basis. Developer TDD is often simply called TDD.

Sample TDD:

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)
4. 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
5. 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
6. Numbers bigger than 1000 should be ignored, so adding 2 + 1001 = 2
7. Delimiters can be of any length with the following format: “//[delimiter]\n” for
example: “//[***]\n1***2***3” should return 6
8. Allow multiple delimiters like this: “//[delim1][delim2]\n” for example
“//[*][%]\n1*2%3” should return 6.
9. make sure you can also handle multiple delimiters with length longer than one char

Conclusion: Thus TDD provides its best results when the code is constantly improved. The
benefits of test-driven development have to do with more than just the simple validation of
correctness. TDD can also drive the design of a program. Because of the testing modules that
are built into the Continuous Integration development model, we can easily make changes to
our Student Assistant App without the fear of breaking the application and hamstringing our
daily operations.

You might also like