Test Driven Development: Un acercamiento práctico con JUnit y Mockito
•Download as PPTX, PDF•
0 likes•691 views
Recommended
Recommended
More Related Content
Similar to Test Driven Development: Un acercamiento práctico con JUnit y Mockito
Similar to Test Driven Development: Un acercamiento práctico con JUnit y Mockito (20)
More from Software Guru
More from Software Guru (20)
Recently uploaded
Recently uploaded (20)
Test Driven Development: Un acercamiento práctico con JUnit y Mockito
- 1. Test Driven Development Roberto Carrera Maldonado
- 2. Once upon a time…
- 3. Once upon a time …
- 4. And they lived happily ever after
- 9. How it works? New Requirement Q & A / Design Write a test Write code that passes that test Refactor (Re/Design)
- 10. Let’s have some fun…
- 12. Some considerations… Tests should be Isolated Not exhaustive but representative Easy and fast to run
- 13. Some considerations… Test features not methods Test names describe what they do, not what they test, so it is domain specific and not specific to the method/class name
- 14. Roberto Carrera Maldonado @rcarreram rcarrera@tacitknowledge.com
- 15. Happy path… with a test
- 16. Cost of defect remediation
- 17. Cost of manage the change
- 18. Roberto Carrera Maldonado @rcarreram rcarrera@tacitknowledge.com
Editor's Notes
- Scenario 01 (Use a cookie moster image - the application eat my exceptions)Few years ago I was working for a company where we were developing and application, and we notice that it was failing without actually understood why it was failing. At the end the problem was with the DAO layer that was eating all the exceptions, none was thrown or log when the component failed.I had many issues with my Project Manager trying to prove her that the component was full of bugs ant that these issues were causing the system to fail without letting us known. The consequences of this problem: (1) I spent a full night rewriting the code and almost got fired because I wanted to replace a piece of code without a proof that it was failing. (2) The system was deliver late and with a long stabilization/cleaning face because bugs were hard to find.For sure my life would be a lot easier if at that time I had a tool that helped me to justify my findings and trace errors in the code.----- Meeting Notes (8/30/11 17:58) -----Add personal cost (reputation)
- Scenario 02Five months ago I joined a team to finish the development of integration code for a brand new website. The original code has been develop by a team from a different company, that was very focus on generated very well javadoc documented code, that reflected the original intent of the class, but in many cases out of date, at the point that some methods have a different name or parameters. Despite the great documentation there was no way to figure out how a change would impact the overall code. We didn't have the time or budget to create a safe net to help us to prevent broken builds or unexpected behaviors. So we took a decision, for every preexisting code that we would need to modify an actual test should be written that reflects the actual intent of that code; and for every new code that we wrote a test should be created first so it helped us to ensure that the expected functionality was in place. The result: we gain confidence on the changes we were doing on previous code and with the new functionality we were certain that the code was actually doing its original intent. Our major win, the whole team was able to focus on generate the required functionality and not to worry about what would break or no.
- In both cases a safety net proved to be necessary to let the team focus on functionality and not on what would break or not. In the first story this mechanism would help the team to prevent bugs that weren't easy to find in the overall system, but that at class level all those issues were easier to solve.On the second case, it actually provided the confidence we required to do any changes being sure that an alarm will fire if any of our changes modify the expected behavior or if the new functionality wasn't compliant with the expected behavior. Overall help us to focus on the important things: GENERATE CODE.Having a test harness in place for your projects helps you not only to take care of the quality, but also provides you other advantages, like higher productivity and cleaner code. TDD is a methodology based on the creation and execution of test to drive your development.In more detail TDD is:
- Is a skill* So it takes time to achieve it.* Requires a repetitive and constant process to acquired it* Personally I have had to invest and important amount of time thinking and working on it, making sure that I use it every time I can, but also making sure that I don't use it where it doesn't fit. I start to consider that TDD was becoming part of my process when I started to feel guilty about don't writing a test before actually modify or write any code.And talking about processes...
- Is a driver for design* Provides an intent * Thinking first on my tests what I want/need/expect let me do a good design without even touching the keyboard* It helps me to design base on how things are used and not how they are implemented. ** This is translate into friendlier APIs, that are focus on the users and not on the developers (us) that are creating them* Part of the contract of a good design is the refactoring and TDD helps me to do it, for free** So if I find an area of improvement to my current implementation, I can just do it, run my tests and figure out how things are
- Is a process* This is a personal process that as developer I have.** Does any one have a personal process for development? like PSP?** White board designs, prototypes?* It is a process because it keeps me honest about my implementation** I can not cheat my test, I either implement what the test ask for or it fails ;)* As a process it tells me when I'm done* Provides an intent
- Is a boost for productivity* Provides me an intent * It helps me to reduce the fear and let me focus on generate code and changes in my application.** Don't spend time thinking what can be broken, concentrate in local things, not on the overall picture** Self protection (when you are coding, and then someone distract you, it remembers your intention and let you know what is failing)** Your focus is on narrow things* It gives me confidence in getting my goal. Because I know I can be focus on doing my code, being confident that if a change breaks the code the test will let me know that.* Reliable code lets QA team focus on larger issues. No test monkeys.Now lets talk about a little bit on how to implement TDD in your current projects using the following sample
- Red bar/Green bar (Write test - Execute - Write code to make it pass - Run the test - Refactor/Add functionality - Run test) First we write the test: We are making design decisions, designing the API; i.e we are forcing ourselves to think hard about how we want the code to be usedWrite just enough code: Write enough code to make the test pass. Refactor: Take a step back, look at your design and figure out ways of making it better
- Lets write a servlet that changes the password of a user into a given applicationThe user will provide her current user/password and the new password that must follow the following convention: length of at least 8 characters and different from the current passwordThe application will check in the database if the current credentials are valid, if so then it will validate the new password against the previous rules. For valid new password it will do the change in the database and redirect the user to a confirmation page. In case the password is invalid the application will redirect the user to an error page.
- ----- Meeting Notes (8/30/11 17:58) -----No crees código sin tests
- Talk about discovering: you need maintainable and extensible code that's easy to changeso you can react to the late discoveryWhen your developer is not anymore in that project or it just can’t remember the code she wrote: if feature X is implemented in January, and the bug is found in November, it’s a lot harder to fix. Example Developer X quit or is fire, how you fix it? How much it will cost?
- The image with different modules that has a cost of C, but when it starts to grow the complexity of the application and the risk of generate introduce bugs are higherCreate diagram (http://www.infoq.com/presentations/TDD-Managers-Nicolette-Scotland)