Test First Refresh Second: Test-Driven Development in Grails
•
10 likes•1,944 views
Grails provides solid support for unit testing of parts of your application that are usually very difficult to test. Learn how to enable test-first development practices using the Grails framework.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Test First Refresh Second: Test-Driven Development in Grails
Similar to Test First Refresh Second: Test-Driven Development in Grails (20)
More from Tim Berglund
More from Tim Berglund (10)
Recently uploaded
Recently uploaded (20)
Test First Refresh Second: Test-Driven Development in Grails
- 1. Test First, Refresh Second Test-Driven Development with Tim Berglund October, 2009
- 2. TDD
- 3. Failure to Write Tests?
- 5. KINDS OF TESTING UNIT TESTING
- 6. KINDS OF TESTING UNIT TESTING XUNIT
- 8. KINDS OF TESTING INTEGRATION TESTING
- 9. KINDS OF TESTING INTEGRATION TESTING XUNIT EXTENSIONS
- 10. KINDS OF TESTING INTEGRATION TESTING XUNIT EXTENSIONS TESTNG
- 11. KINDS OF TESTING
- 12. KINDS OF TESTING FUNCTIONAL TESTING
- 13. KINDS OF TESTING FUNCTIONAL TESTING
- 14. KINDS OF TESTING FUNCTIONAL TESTING
- 15. UNIT TESTS
- 16. EXECUTABLE
- 17. ISOLATED
- 18. AUTOMATED
- 19. ISOLATED?
- 20. WEB APP ISOLATION CHALLENGES
- 21. WEB APP ISOLATION CHALLENGES DATABASE
- 22. WEB APP ISOLATION CHALLENGES DATABASE SERVLET CONTAINER
- 23. WEB APP ISOLATION CHALLENGES DATABASE SERVLET CONTAINER HTTP INTERACTION
- 24. WEB APP ISOLATION CHALLENGES DATABASE SERVLET CONTAINER HTTP INTERACTION PAGE RENDERING
- 25. WEB APP ISOLATION CHALLENGES DATABASE SERVLET CONTAINER HTTP INTERACTION PAGE RENDERING ENTERPRISE INTEGRATION POINTS
- 26. TO THE RESCUE! (especially 1.1 and later)
- 27. THE GOOD STUFF
- 28. THE GOOD STUFF GrailsUnitTestCase ControllerUnitTestCase
- 29. THE GOOD STUFF
- 30. THE GOOD STUFF mockDomain mockController mockLogging mockConfig
- 31. METACLASS MAGIC
- 32. mockDomain
- 34. mockDomain SUPPORTS findAll() findAllByXXX() get() read() getAll() ident() exists()
- 35. mockDomain SUPPORTS findAll() count() findAllByXXX() list() get() validate() read() save() getAll() delete() ident() discard() exists()
- 36. mockDomain
- 38. mockDomain DOES NOT SUPPORT Criteria Builders HQL Persistent Class Inheritance findWhere() findAllWhere()
- 39. mockController
- 40. mockController SUPPORTS
- 41. mockController SUPPORTS log request response session params flash
- 42. mockController SUPPORTS log forward() request redirect() response render() session withFormat() params withForm() flash
- 43. mockController
- 44. mockController SUPPORTS
- 45. mockController SUPPORTS forwardArgs redirectArgs renderArgs template modelAndView
- 46. mockLogging
- 47. mockLogging ADDS MOCKED LOG PROPERTY
- 48. mockLogging ADDS MOCKED LOG PROPERTY SENDS OUTPUT TO SYSTEM.OUT
- 49. mockLogging ADDS MOCKED LOG PROPERTY SENDS OUTPUT TO SYSTEM.OUT IGNORES DEBUG AND TRACE BY DEFAULT
- 50. mockLogging ADDS MOCKED LOG PROPERTY SENDS OUTPUT TO SYSTEM.OUT IGNORES DEBUG AND TRACE BY DEFAULT CAN ENABLE DEBUG WITH A SWITCH
- 51. mockConfig
- 52. mockConfig REPLACES DEFAULT GRAILS CONFIG IN grailsApplication.config
- 53. mockConfig REPLACES DEFAULT GRAILS CONFIG IN grailsApplication.config READS FROM A STRING
- 55. GrailsUnitTestCase INTRINSIC PROPERTIES applicationContext errorsMap INTRINSIC METHODS mockFor mockDomain mockController mockTagLib mockConfig
- 57. ControllerUnitTestCase INTRINSIC PROPERTIES
- 58. ControllerUnitTestCase INTRINSIC PROPERTIES mockRequest mockResponse mockSession forwardArgs redirectArgs renderArgs mockParams mockFlash
- 60. ControllerUnitTestCase AUTOMATICALLY MOCKS CONTROLLER FROM TEST CLASS NAME
- 62. LET’S USE THIS!
- 63. OUR APP USER GROUP MEMBERSHIP MANAGER
- 64. STORIES AS AN UNREGISTERED USER, I WANT TO SIGN UP ON THE SITE.
- 65. STORIES AS A REGISTERED USER, I WANT TO SEE UPCOMING EVENTS.
- 66. STORIES AS AN ADMINISTRATOR, I WANT TO HAVE FULL CRUD CAPABILITIES ON MEETINGS.
- 67. STORIES AS AN ADMINISTRATOR, I WANT TO SEE WHO IS ATTENDING AN EVENT.
- 68. STORIES AS A REGISTERED USER, I WANT TO BE ABLE TO RSVP TO AN EVENT.
- 69. LIVE CODING!
- 70. THE CONCLUSION?
- 71. IT WORKS!
- 72. THERE ARE REAL LIMITATIONS
- 73. INTEGRATION AND FUNCTIONAL TESTS ARE NECESSARY
- 74. CREDIBLE WEB APP TDD
- 75. THANK YOU! TIM BERGLUND AUGUST TECHNOLOGY GROUP, LLC http://www.augusttechgroup.com tim.berglund@augusttechgroup.com @tlberglund
- 76. PHOTO CREDITS SHIPPING CONTAINERS: HTTP://WWW.FLICKR.COM/PHOTOS/PHOTOHOME_UK/1494590209/ COMPUTER CONSOLE: HTTP://WWW.FLICKR.COM/PHOTOS/NOSTRI-IMAGO/2910549047/
Editor's Notes
- Test-driven development has reached the status of received orthodoxy. For my part, I don’t object to the idea of a right way of thinking, but in our line of work, we should watch ourselves. There are some people critical of the idea of testing first, and we should listen to them.
- One way to gauge the health of our community is to see what happens to people who don’t toe the line. We don’t want to burn them at the stake. We should listen to them. It’s especially easy to eschew testing in difficult environments, and some people do so. We should ask why.
- Small pieces of code tested in isolation from each other. Typically at the class or method level. Often uses practices like stubbing and mocking to effect isolation. Runs fast, particularly if the IDE has a test runner that doesn’t require booting a new JVM or rebuilding the world.
- Small pieces of code tested in isolation from each other. Typically at the class or method level. Often uses practices like stubbing and mocking to effect isolation. Runs fast, particularly if the IDE has a test runner that doesn’t require booting a new JVM or rebuilding the world.
- Multiple units tested together in collaboration. Usually implies testing our code with a live database and servlet container. Want to test actual ORM, page rendering, service layer, etc. Runs slower. Not suitable for TDD. Should be run by a build server.
- Multiple units tested together in collaboration. Usually implies testing our code with a live database and servlet container. Want to test actual ORM, page rendering, service layer, etc. Runs slower. Not suitable for TDD. Should be run by a build server.
- Multiple units tested together in collaboration. Usually implies testing our code with a live database and servlet container. Want to test actual ORM, page rendering, service layer, etc. Runs slower. Not suitable for TDD. Should be run by a build server.
- Testing features of the fully assembled system. Best to do in a story-driven fashion. Certainly slow, requires significant server infrastructure (compared to JUnit), should be run by a build server.
- Testing features of the fully assembled system. Best to do in a story-driven fashion. Certainly slow, requires significant server infrastructure (compared to JUnit), should be run by a build server.
- Testing features of the fully assembled system. Best to do in a story-driven fashion. Certainly slow, requires significant server infrastructure (compared to JUnit), should be run by a build server.
- Our main concern tonight will be unit tests. You really can’t do TDD with integration or functional tests, because they take too long to run. There are two things that are important when considering unit tests.
- These are code, not human procedures.
- Each unit test should make assertions about a small, coherent chunk of code. Moreover, it should not matter in what order we run them. Each should be fully responsible for creating the state it needs to run its code under test.
- Since they are executable, we should be able to have a computer run them very frequently.
- Let’s talk about isolation some more. It’s easy—or can be—when you’re writing APIs in core Java. It’s hard in a web app. Why is that? (DB, servlet container, browser, HTTP loop)
- Besides the web and database problems, we usually have problems related to integration points, since
- Besides the web and database problems, we usually have problems related to integration points, since
- Besides the web and database problems, we usually have problems related to integration points, since
- Besides the web and database problems, we usually have problems related to integration points, since
- Besides the web and database problems, we usually have problems related to integration points, since
- The Testing plugin was made a part of core Grails as of the 1.1 release. It revolutionized the way we can test Grails apps.
- These are extensions to GroovyTestCase, which is itself an extension to JUnit’s TestCase.
- These four methods form the substance of the features provided by the two base testing classes. We’ll discuss their features in turn, then demonstrate some of them.
- At runtime, the simple domain, controller, service, job, and tag library classes you write in Groovy are modified significantly at the MetaClass level. This requires the Spring container to be booted, etc., all of which takes time. These test methods make direct modifications to the MetaClass of the classes under test to mock the desired behavior in a convincing way.
- findWhere() is coming in 1.2
- findWhere() is coming in 1.2
- As properties of the mocked class, and as properties of the test case class if extended from ControllerUnitTest
- As properties of the mocked class, and as properties of the test case class if extended from ControllerUnitTest
- Is automatically called by mockController
- Is automatically called by mockController
- Is automatically called by mockController
- Is automatically called by mockController
- Provides certain properties and method to the test case class.
- It does important things. If you override setUp() (and you probably should), remember to call this.
- These are all provided to the class under test automatically.
- This is a convenience feature. It does not mock relevant domain classes.
- Users have name, email, company title, membership status.
- Meetings have a start time, end time, location, description, member price, and nonmember price.
- As an
- As an
- It’s best to determine the shape of the testing framework and the functionality it covers, and try to write testable code on that basis. Usually that results in better factoring anyway.
- You’ll use criteria if you’re doing anything of any complexity.
- It’s economical to write tests this way, and enough of the framework is mocked to get the job done. You can actually write code against your domain model and controllers while testing first.