Unit Testing in Java
2 likes1,455 views
The document discusses unit testing in Java. It introduces the JUnit testing framework and describes unit testing methodology, including how to design testable code, write maintainable tests, and handle indirect inputs and outputs through stubs and mocks. The document provides guidance on test-driven development and testing legacy code. It contrasts unit testing with functional testing and discusses best practices for test granularity, assertions, and fixtures.
Editor's Notes
- #5: Automate tests: Cost not proportional to number of test runs like manual is More repeatable and less error-prone More fun and more likely to happen Goal of testing is to prevent defects, not find as many as possible. Root-cause analysis, fix the source of the problem.
- #7: Mention how I always mix up the TestCase with a test case which is a certain scenario.
- #8: Show the test results links for branches. Show Cobertura report.
- #9: Show LoadModel test case Question: What happened to Error outcome from JUnit?
- #10: Can either make static Assert.assertFoo() calls or use a static import to shorten this down. Show example of exception assertion in DVAdapterTest class.
- #14: Expected objects: don’t compare pointX and pointY variables, just compare Point (object) Guard assertion: assertNotNull(collection) before asserting about its contents Custom assert: assertExactlyOneChildNode(node); created during test refactoring
- #15: Clean Slate: watch out for code duplication Standard: brittleness from dependence on external data Shared: test run wars, interactions between tests, unrepeatable tests, example is our DV_TEST database
- #18: A mock object fills the role of the real dependency by acting just like it.
- #19: A mock object fills the role of the real dependency by acting just like it.
- #20: A mock object fills the role of the real dependency by acting just like it.
- #21: A mock object fills the role of the real dependency by acting just like it.
- #22: A mock object fills the role of the real dependency by acting just like it.
- #23: A mock object fills the role of the real dependency by acting just like it.
- #24: Install Stub into SUT by: Passing as argument Passing as constructor argument Set explicitly with setter method Set in the environment (preferences, system property, JNDI) Discuss Active versus Passive stubs (Active stubs participate in the verification)
- #25: Real component: Talk about DBUnit and embedded databases like HSQL for Merge tests. Mock object: Show MockRunner objects in LoadModel test for working JDBC. Mention that mock objects don’t need to be created by hand. Projects like EasyMock, jMock, and MockMaker can auto-generate.
- #26: Real component: Talk about DBUnit and embedded databases like HSQL for Merge tests. Mock object: Show MockRunner objects in LoadModel test for working JDBC. Mention that mock objects don’t need to be created by hand. Projects like EasyMock, jMock, and MockMaker can auto-generate.
- #27: Real component: Talk about DBUnit and embedded databases like HSQL for Merge tests. Mock object: Show MockRunner objects in LoadModel test for working JDBC. Mention that mock objects don’t need to be created by hand. Projects like EasyMock, jMock, and MockMaker can auto-generate.
- #28: Real component: Talk about DBUnit and embedded databases like HSQL for Merge tests. Mock object: Show MockRunner objects in LoadModel test for working JDBC. Mention that mock objects don’t need to be created by hand. Projects like EasyMock, jMock, and MockMaker can auto-generate.
- #29: Real component: Talk about DBUnit and embedded databases like HSQL for Merge tests. Mock object: Show MockRunner objects in LoadModel test for working JDBC. Mention that mock objects don’t need to be created by hand. Projects like EasyMock, jMock, and MockMaker can auto-generate.
- #30: Real component: Talk about DBUnit and embedded databases like HSQL for Merge tests. Mock object: Show MockRunner objects in LoadModel test for working JDBC. Mention that mock objects don’t need to be created by hand. Projects like EasyMock, jMock, and MockMaker can auto-generate.
- #31: Real component: Talk about DBUnit and embedded databases like HSQL for Merge tests. Mock object: Show MockRunner objects in LoadModel test for working JDBC. Mention that mock objects don’t need to be created by hand. Projects like EasyMock, jMock, and MockMaker can auto-generate.
- #32: Talk about how much setup some tests require. Then show the answer: separation of concerns Then ask when should we test?
- #33: Talk about how much setup some tests require. Then show the answer: separation of concerns Then ask when should we test?
- #34: Talk about how much setup some tests require. Then show the answer: separation of concerns Then ask when should we test?
- #35: Talk about how much setup some tests require. Then show the answer: separation of concerns Then ask when should we test?
- #36: Talk about how much setup some tests require. Then show the answer: separation of concerns Then ask when should we test?
- #37: Talk about how much setup some tests require. Then show the answer: separation of concerns Then ask when should we test?
- #38: Talk about how much setup some tests require. Then show the answer: separation of concerns Then ask when should we test?
- #39: See section 11 page 7 last slide for reasons.
- #40: Mention that this can be hard as the original code wasn’t written with testability in mind. Likely it is highly coupled and not cohesive. Normally, you will need to iterate around the “write tests & refactor” loop until you have decent coverage.
- #41: Show LoadModelTest for the Mockrunner example. Show AbstractPreferencesTestCase for the DBUnit.