Unit tests benefits
•
3 j'aime•6,133 vues
The presentation explains JUnit tests benefits for business
Recommandé
Contenu connexe
Tendances
Tendances (19)
Similaire à Unit tests benefits
Similaire à Unit tests benefits (20)
Plus de Kate Semizhon
Plus de Kate Semizhon (17)
Dernier
Dernier (20)
Unit tests benefits
- 4. TYPES OF TESTS Test Type To Confirm That: Unit Tests Low level functions and classes work as expected under a variety of inputs. Integration Tests Integrated modules work together and in conjunction with infrastructure such as message queues and databases. Acceptance Tests Your application and key user flows works as a complete black box when driven via the user interface. Load Tests Your application performs well under simulated real world user load. Performance Tests The application meets performance requirements and response times under real world load scenarios. Simulation Tests Your application works in device simulation environments. (This is growing in importance in the mobile world where you need to test software on diverse emulated mobile devices.) Smoke Tests Tests to validate the state and integrity of a freshly deployed environment. Quality Tests Application code is high quality – identified through techniques such as static analysis, conformance to style guides, code coverage etc.
- 5. Impact on business Time to fix
- 8. >> Unit tests are written by programmers to ensure that the code does what they intend it to do. Uncle Bob (Robert Martin) >> It is difficult to claim that you are Agile, if you are not writing lots of automated test cases, and writing them before you write the code that makes them pass.
- 9. LEGACY CODE
- 10. - Edit and Pray Cover and Modify.
- 11. TEST TYPES 11 Clas s Clas s Clas s Clas s Clas s Clas s Clas s DB Unit Integration Acceptance
- 12. GOAL - isolate each part of the program - show that the individual parts are correct. Clas s Clas s Clas s Clas s Clas s Clas s Clas s DB Unit
- 13. KPI 100 % coverage != good tests
- 19. FEEL SAFER
- 22. BONUS: KNOW EXACTLY WHAT IS BROKEN
- 24. TOOLS UNIT TESTS
- 25. TOOLS
- 26. TDD
- 27. BDD User story As a [Role] I want [Feature] So that I receive [Value] Test scenario Given [Context] When [Event Occurs] Then [Outcome]
- 29. MOCKITO Seller seller = mock(Seller.class); Shop shop = new Shop(seller); public void shouldBuyBread() throws Exception { //given given(seller.askForBread()).willReturn(new Bread()); //when Goods goods = shop.buyBread(); //then assertThat(goods, containBread()); }
- 30. DEMO UNIT TESTS
- 31. WHAT COULD BE TESTED Custom Business logic Validation Frontend API
Notes de l'éditeur
- JUnit cartoon
- CI
- Points WHY?
- Who?
- https://sites.google.com/site/unclebobconsultingllc/tdd-with-acceptance-tests-and-unit-tests But there are two different kinds of automated tests recommended by the Agile disciplines. Unit tests, which are written by programmers, for programmers, in a programming language. And acceptance tests, which are written by business people (and QA), for business people, in a high level specification language (like FitNesse www.fitnesse.org).
- Complex code with few dependencies (top left). Typically this means self-contained algorithms for business rules or for things like sorting or parsing data. This cost-benefit argument goes strongly in favour of unit testing this code, because it’s cheap to do and highly beneficial. Trivial code with many dependencies (bottom right). I’ve labelled this quadrant “coordinators”, because these code units tend to glue together and orchestrate interactions between other code units. This cost-benefit argument is in favour of not unit testing this code: it’s expensive to do and yields little practical benefit. Your time is finite; spend it more effectively elsewhere. Complex code with many dependencies (top right). This code is very expensive to write with unit tests, but too risky to write without. Usually you can sidestep this dilemma by decomposing the code into two parts: the complex logic (algorithm) and the bit that interacts with many dependencies (coordinator). Trival code with few dependencies (bottom left). We needn’t worry about this code. In cost-benefit terms, it doesn’t matter whether you unit test it or not.
- http://blog.typemock.com/2011/11/28/10-reasons-to-write-unit-tests Test complex scenarios quickly, without having to manually reproduce them in the application. By testing often, you don’t break the application as you go. You can’t always know the indirect implications of what you’re writing, especially if you didn’t write the original application. You ensure readability. A unit test makes the purpose of your code easier to understand. You ensure maintainability. Unit-testing forces you to better encapsulate functionality, thus making it easier to maintain and add new features. Refactor without worries. Run the tests to make sure everything still functions as intended. Save time on testing. You can test the entire application at the speed of your CPU. Feel safer. How many times were you afraid to add a new feature or change something in your application’s core? No more! Bonus: know exactly what is broken. Instead of hunting for an obscure bug, let the tests tell you what’s wrong and why. Example: the application will tell you when you add an item to a cart but the cart still appears empty. It will also tell you what item you tried to add for the cart to break.
- Test complex scenarios quickly, without having to manually reproduce them in the application.
- You ensure readability. A unit test makes the purpose of your code easier to understand.
- You ensure maintainability. Unit-testing forces you to better encapsulate functionality, thus making it easier to maintain and add new features.
- Feel safer. How many times were you afraid to add a new feature or change something in your application’s core? No more!
- Refactor without worries. Run the tests to make sure everything still functions as intended.
- Save time on testing. You can test the entire application at the speed of your CPU.
- Bonus: know exactly what is broken. Instead of hunting for an obscure bug, let the tests tell you what’s wrong and why. Example: the application will tell you when you add an item to a cart but the cart still appears empty. It will also tell you what item you tried to add for the cart to break.
- By having to Craft unit tests, developers are forced to think as consumers of their code. This gives them an extra motivation to build an application programming interface (API) that is clear, and easy to implement.
- Fittnesse screenshot There are differences – BDD is more “high level” dealing with specifications and was intended to be used by domain experts as well as developers Given a customer previously bought a black sweater from me And I currently have three black sweaters left in stock When he returns the sweater for a refund Then I should have four black sweaters in stock define a test set for the unit first; then implement the unit; finally verify that the implementation of the unit makes the tests succeed.
- To be discussed
- http://iosunittesting.com/links/