Upload
xavi-hidalgo
View
671
Download
4
Tags:
Embed Size (px)
Citation preview
Unit testingTDD
XAVI HIDALGO · [email protected]
&@xavi_reload
edhttp://apiumtech.com/blog/http://es.linkedin.com/in/
xavireloaded/
Unit testingTDD &
@xavi_reloadedhttp://apiumtech.com/
blog/http://es.linkedin.com/in/xavireloaded/
XAVI HIDALGO · [email protected]
Programmers are constantly in maintenance mode(The Pragmatic Programmer)
XAVI HIDALGO · [email protected]
www.apiumtech.com
A closed, fixed-requirements system is a programmers’
chimera:
● requirements always change on the way
(unexpectedly AND unpredictably)
● even if not, you always discover new requirements as you
dig into the system and the code. This implies change
● even if not, the system needs to be bug-fixed, which
implies change
Design principles in agile
XAVI HIDALGO · [email protected]
www.apiumtech.com
DRY YAGNI KISS
Don’t repeat yourself You aren’t gonna need it Keep it simple stupid
Or equivalents:Say it Once and only onceChoose the Simplest strategy that could possibly work“keep it DRY, shy and tell the other guy” (from the authors of Pragmatic Programmer)
Emergent/evolutionary design
Enabling Practices from XP
XAVI HIDALGO · [email protected]
www.apiumtech.com
“Enabling” = Practices that enable an evolutionary design when not used, the result of evolutionary design is always: Entropy
Engineering Practices (in order of application):● Unit Testing (allows:)● Refactoring● Automated Build● Continuous Integration● Continuous design● Emergent architecture● Pair Programming
Refactoring is forbidden without tests = high risk with none business value Without Unit Testing there’s not evolutionary design
Agile learning steps(from Osherove)
XAVI HIDALGO · [email protected]
www.apiumtech.com
1. Learn Good Unit Testing
2. Learn Test Driven Development (TDD)
3. Learn S.O.L.I.D. and advanced OO Design principles
Meanwhile: remove duplication (be DRY!!)
Unit Testing Economics
XAVI HIDALGO · [email protected]
www.apiumtech.com
UT and TDD are productivity development tools, NOT (only) quality or testing tools.
TDD Principles
XAVI HIDALGO · [email protected]
www.apiumtech.com
GOALSClean Code that works, Now!
RULES1. Write new code only if an automated test has failed2. Eliminate duplication
PRACTICESmall cycles of /red/green/refactor
A very simple development workflow
XAVI HIDALGO · [email protected]
www.apiumtech.com
#red#green
#refactor
Practice 1 (basic tests)
XAVI HIDALGO · [email protected]
www.apiumtech.com
Create a class called “Dog” Create a method called sayHello(String greeting) sayHello returns “wroof”+ greeting
● Make a test on the sayHello method● Use SetUp() Dropdown()● Use DataProviders● Use different Assertions
Practice 2 (more complex tests)
XAVI HIDALGO · [email protected]
www.apiumtech.com
Create a class called “Petshop” Class petshop has a Dog PropertyCreate a method called saySomething() saySomething returns Dog.sayHello()
● Make a test on the saySomething method
● Use Stubs, Mocks and Fakes● Run the suite● Use different Assertions
Unit Test Conclusions
XAVI HIDALGO · [email protected]
www.apiumtech.com
Did you seesomething
interesting ?
How did we...
XAVI HIDALGO · [email protected]
www.apiumtech.com
Refactoring ?
Automated Build ?
Continuous Integration ?
Continuous design ?
Emergent architecture ?
Pair Programming ?
Unit testingTDD
XAVI HIDALGO · [email protected]
&@xavi_reload
edhttp://apiumtech.com/blog/http://es.linkedin.com/in/
xavireloaded/
The great questionAre UT sufficient to replace manual test?
XAVI HIDALGO · [email protected]
www.apiumtech.com
Manual test is still indispensable ● Human interactions and validation● Functional feedback● Integration tests difficult to automate● Manual test has a completely different role:● Remember: UT & TDD are design/develop tools, NOT
testing tools
Then what is the great gain? (see above and previous)
● All that you can validate automatically you do● Manual test is executed only few times – it’s the last
validation
In legacy code phase accurate Manual Tests are still needed
NO
Practice 1 (KATA)
XAVI HIDALGO · [email protected]
www.apiumtech.com
http://osherove.com/tdd-kata-1/
Practice 1 (KATA) String Calculator
XAVI HIDALGO · [email protected]
www.apiumtech.com
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
numbers3. Remember to solve things as simply as possible so that you force yourself to
write tests you did not think about4. Remember to refactor after each passing test
Practice 1 (KATA) String Calculator
XAVI HIDALGO · [email protected]
www.apiumtech.com
1. Allow the Add method to handle an unknown amount of numbers
Practice 1 (KATA) String Calculator
XAVI HIDALGO · [email protected]
www.apiumtech.com
1. 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)3. Support different delimitersto 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 ‘;’ .
4. the first line is optional. all existing scenarios should still be supported
Practice 1 (KATA) String Calculator
XAVI HIDALGO · [email protected]
www.apiumtech.com
1. 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
TDD Conclusions
XAVI HIDALGO · [email protected]
www.apiumtech.com
Did you seesomething
interesting ?
The End
XAVI HIDALGO · [email protected]
www.apiumtech.com
ESSENTIAL BIBLIOGRAPHY
[Osherove, R., The Art of Unit Testing, 2009][Meszaros, G., xUnit Test Patterns, 2007][Beck, K., Test Driven Development by Example, 2002][Fowler, M. Beck, K., Refactoring, 1999][Osherove, R., Iserializable – Roy Osherove Blog, http://weblogs.asp.net/rosherove/][Meszaros, G., http://xunitpatterns.com/][Kniberg, H., Scrum and Xp from the trenches, 2007][Succi et al., eXtreme Programming eXamined, 2001][Feathers, C., Working Effectively with Legacy Code, 2004][Hunt, A. et al., The Pragmatic Programmer, 1999]