SUPER importante: MÉTRICAS que demuestren que automatizar requiere menos esfuerzo y da un mayor valor.
There are multiple reasons to automate besides our saying you need to have automation to be successful using agile. Our list includes the following:
Manual testing takes too long.
Manual processes are error prone.
Automation frees people to do their best work.
Automated regression tests provide a safety net.
Automated tests give feedback early and often.
Tests and examples that drive coding can do more.
Automation can be a good return on investment.
Bret’s list of automation problems looks like this:
Only using spare time for test automation doesn’t give it the focus it needs.
There is a lack of clear goals.
There is a lack of experience.
There is high turnover, because you lose any experience you may have.
A reaction to desperation is often the reason why automation is chosen, in which case it can be more of a wish than a realistic proposal.
There can be a reluctance to think about testing; the fun is in the automating, not in the testing.
Focusing on solving the technology problem can cause you to lose sight of whether the result meets the testing need.
Our list of barriers to successful test automation is based on the experiences we’ve had with our own agile teams as well as that of the other teams we know.
SUPER importante: MÉTRICAS que demuestren que automatizar requiere menos esfuerzo y da un mayor valor.
Test automation is scary to those who’ve never mastered it, and even to some who have.
So we may say, “We are supposed to deliver on February 1. If we want to meet that date, we don’t have time to automate any tests. We’ll have to do whatever manual tests can be done in that amount of time and hope for the best. We can always automate the tests later.”
This is the road to perdition. Some manual tests can get done, but maybe not the important manual exploratory tests that would have found the bug that cost the company hundreds of thousands of dollars in lost sales.
[] Buscar fundamentos para reducir la deuda técnica. Impacto económico, etc.
[] Cómo hago pruebas unitarias de la capa de presentación?
[] ¿Cómo diseñar con los tests funcionales automatizados en mente?
equals(), because one $5 is pretty much as good as another.Following are two of the three strategies I know for quickly getting to green:
Fake It—. Return a constant and gradually replace constants with variables until you have the real code.
Use Obvious Implementation—. Type in the real implementation.
When I use TDD in practice, I commonly shift between these two modes of implementation. When everything is going smoothly and I know what to type, I put in Obvious Implementation after Obvious Implementation (running the tests each time to ensure that what's obvious to me is still obvious to the computer).
Following are two of the three strategies I know for quickly getting to green:
Fake It—. Return a constant and gradually replace constants with variables until you have the real code.
Use Obvious Implementation—. Type in the real implementation.
There is a third style of TDD, Triangulation, which we will demonstrate in Chapter 3. However, to review, we
Translated a design objection (side effects) into a test case that failed because of the objection
Got the code to compile quickly with a stub implementation
Made the test work by typing in what seemed to be the right code
Dollar twice) is a common theme of TDD. The longer I do this, the better able I am to translate my aesthetic judgments into tests. When I can do this, my design discussions become much more interesting.Dollar twice) is a common theme of TDD. The longer I do this, the better able I am to translate my aesthetic judgments into tests. When I can do this, my design discussions become much more interesting.If dependency is the problem, duplication is the symptom. Duplication most often takes the form of duplicate logic—the same expression appearing in multiple places in the code. Objects are excellent for abstracting away the duplication of logic.
Unlike most problems in life, where eliminating the symptoms only makes the problem pop up elsewhere in worse form, eliminating duplication in programs eliminates dependency.
My goal is for you to see the rhythm of Test-Driven Development (TDD), which can be summed up as follows.
Quickly add a test.
Run all tests and see the new one fail.
Make a little change.
Run all tests and see them all succeed.
Refactor to remove duplication.
The surprises are likely to include
How each test can cover a small increment of functionality
How small and ugly the changes can be to make the new tests run
How often the tests are run
How many teensy-weensy steps make up the refactorings
It has been over ten years since Test Driven Development (TDD) made its debut in the industry. It came in as part of the Extreme Programming (XP) wave, but has since been adopted by Scrum, and virtually all of the other Agile methods. Even non-Agile teams practice TDD.
When, in 1998, I first heard of “Test First Programming” I was skeptical. Who wouldn’t be? Write your unit tests first? Who would do a goofy thing like that?