Grails unit testing

  • Upload
    pleeps

  • View
    3.630

  • Download
    4

Embed Size (px)

DESCRIPTION

testing slideshare api

Citation preview

  • 1. Grails Unit Testing By:-Uday & Imran

2. Agenda

  • Testing overview

3. Understanding Unit Testing 4. Goals of Unit Testing 5. Spock Unit Testing 6. Writing Unit test cases 7. Demo 8. Exercise 9. What do we test ?

  • What a program is supposed to do==What the program actually does

10. Motivation

  • People are not perfect
  • We make errors in design and code

Testing is an investment

  • Over the time the tests build, the early investment in writing test cases pays dividends later as the size of the application grows.

11. A way of thinking

  • Designing and coding are creative

12. Testing is destructive.The primary goal is to break the software 13. Very often the same person does coding and testing 14. Need 'split personality': when you start testing, becomeparanoidandmalicious.Surprisingly hard to do: people don't like finding out that they make mistakes. 15. We have more code base to handle 16. Testing

  • Testingis a process of executing software with the intent of finding errors.

17. Good Testinghas high probability of finding as-yet-undiscovered errors 18. Successful Testingdiscovers errors

  • If it did not find any errors, need to ask whether our testing approach is good or not

19. Testing needs to be the integral part at each level of development

  • Unit testing (white box)

20. Integration testing (white box) 21. Functional testing (black box) 22. Acceptance testing 23.

  • Understanding Unit Testing
  • Unit testing is a method by which individual units of source code are tested to determine if they are fit for use.

24. A unit is the smallest testable part of an application. 25. Each test case is independent from the others: substitutes like method stubs, mock objects, can be used to assist testing a module in isolation. 26. A unit test provides a strict, written contract that the piece of code must satisfy. 27. It tests individual methods or blocks of code without considering for surrounding infrastructure. 28. It is integral part of the development, so developers write unit test cases. 29. Shortcomings of Unit Testing

  • Test cases written to suit programmers implementation (not necessarily specification)

30. The actual database or external file is never tested directly by TDD. 31. It is highly reliant on Refactoring and Programmer skills 32. Not every code is testable. 33.

  • Advantages of Unit Testing
  • Facilitates change

34. Unit testing allows the programmer to refactor code at a later date, and make sure the module still works correctly 35. Simplifies integration 36. Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach.By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier. 37. Documentation 38. Unit testing provides a sort of living documentation of the system 39. Design 40. When software is developed using a test-driven approach, the unit test may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behaviour. 41. Quality Improves the quality, readability and testability of the code 42. Spock

  • A developer testing framework for Java and Groovy application

43. Based on Groovy 44. What makes it stand out from the crowd is its beautiful and highly expressive specification language 45. Getting started Basic Terms used in Spock 46. Fields

  • Field:store objects belonging to the specification's fixture
  • def obj = new ClassUnderSpecification()

47. @Shared res =newVeryExpensiveResource() 48. static final PI = 3.141592654 49. Fixture Methods

  • def setup() {}// run before every feature method

50. def cleanup() {}// run after every feature method 51. def setupSpec() {}// run before the first feature method 52. def cleanupSpec() {}// run after the last feature method 53. Feature methods def "pushing an element on the stack"() { // blocks go here } 54. Blocks

  • setup: (optional)

55. when, then, (always occure togethor)

  • when:(stimulus)

56. then: (response)expect: useful in situations where it is more natural to describe stimulus and expected response in a single expression 57. Example when: stack.push(elem) then: !stack.empty stack.size() == 1 stack.peek() == elem 58. Example when: def x = Math.max(1, 2) then: x == 2 expect: Math.max(1, 2) == 2 59. Where (for data driven testing)

  • data-driven feature methods

60. where block always comes last in a method expect: Math.max(a, b) == c where: [a,b,c]