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.