{"id":1447,"date":"2023-05-14T17:31:19","date_gmt":"2023-05-15T00:31:19","guid":{"rendered":"https:\/\/bullyrooks.com\/?p=1447"},"modified":"2023-05-14T17:31:22","modified_gmt":"2023-05-15T00:31:22","slug":"unit-tests-vs-component-tests-which-ones-better-for-software-quality","status":"publish","type":"post","link":"https:\/\/bullyrooks.com\/index.php\/2023\/05\/14\/unit-tests-vs-component-tests-which-ones-better-for-software-quality\/","title":{"rendered":"Unit Tests vs. Component Tests: Which One’s Better for Software Quality?"},"content":{"rendered":"\n

Introduction<\/h2>\n\n\n\n

If you’re considering software testing and are torn between unit tests and component tests, this article is for you. We will present the advantages and disadvantages of each testing method, helping you select the right one for your project. Additionally, we’ll discuss how combining both techniques can lead to improved software quality.<\/p>\n\n\n\n

Our Code Example<\/h2>\n\n\n\n

Here’s a very simple 3 layer spring REST endpoint example that has a POST endpoint to create a book and a GET endpoint to retrieve a book<\/p>\n\n\n\n

\/\/ Controller\n@RestController\npublic class BookController {\n    @Autowired\n    private BookService bookService;\n\n    @GetMapping(\"\/book\/{id}\")\n    public ResponseEntity<Book> getBookById(@PathVariable Long id) {\n        Book book = bookService.findById(id);\n        return ResponseEntity.ok(book);\n    }\n\n    @PostMapping(\"\/book\")\n    public ResponseEntity<Book> createBook(@RequestBody Book book) {\n        Book savedBook = bookService.createBook(book);\n        return ResponseEntity.ok(savedBook);\n    }\n}\n\n\/\/ Service\n@Service\npublic class BookService {\n    @Autowired\n    private BookRepository bookRepository;\n\n    public Book findById(Long id) {\n        return bookRepository.findById(id).orElseThrow(() -> new RuntimeException(\"Book not found\"));\n    }\n\n    public Book createBook(Book book) {\n        return bookRepository.save(book);\n    }\n}\n\n\/\/ Repository\npublic interface BookRepository extends JpaRepository<Book, Long> {\n}\n<\/code><\/pre>\n\n\n\n
The Drawbacks of Unit Tests<\/h2>\n\n\n\n
Unit tests focus on individual components or functions within a codebase. They\u2019re vital for ensuring your code is up to par, but they come with some challenges:<\/p>\n\n\n\n
    \n
  1. Too much focus on the nitty-gritty: Unit tests can be fragile since they’re all about specific implementation details. They might break when you change the codebase.<\/li>\n\n\n\n
  2. A lot to keep up with: When you’ve got a ton of unit tests, keeping them up to date can be a real headache.<\/li>\n\n\n\n
  3. Not enough integration coverage: Unit tests might not cover how components work together, so you could miss some integration problems.<\/li>\n\n\n\n
  4. False confidence: A bunch of passing unit tests could make you feel good about your code quality, even if you haven’t covered all the bases.<\/li>\n\n\n\n
  5. Enforcing the design: Isolating each class via mocks creates a hardened interface between each service.  If you aim to modify your design, you\u2019ll find that you\u2019ll have to change not only multiple classes but also multiple tests.<\/li>\n<\/ol>\n\n\n\n
    Here’s what the unit tests covering these endpoints would look like, using mocks to isolate each layer:<\/p>\n\n\n\n
    Controller:<\/p>\n\n\n\n
    @RunWith(SpringRunner.class)\n@WebMvcTest(BookController.class)\npublic class BookControllerTest {\n\n    @Autowired\n    private MockMvc mockMvc;\n\n    @MockBean\n    private BookService bookService;\n\n    @Test\n    public void getBookByIdTest() throws Exception {\n        Book book = new Book(1L, \"Test Title\", \"Test Author\");\n        when(bookService.findById(1L)).thenReturn(book);\n\n        mockMvc.perform(get(\"\/book\/1\"))\n                .andExpect(status().isOk())\n                .andExpect(jsonPath(\"$.title\", is(book.getTitle())));\n    }\n\n    @Test\n    public void createBookTest() throws Exception {\n        Book book = new Book(1L, \"Test Title\", \"Test Author\");\n        when(bookService.createBook(any(Book.class))).thenReturn(book);\n\n        mockMvc.perform(post(\"\/book\")\n                        .contentType(MediaType.APPLICATION_JSON)\n                        .content(new ObjectMapper().writeValueAsString(book)))\n                .andExpect(status().isOk())\n                .andExpect(jsonPath(\"$.title\", is(book.getTitle())));\n    }\n}\n<\/code><\/pre>\n\n\n\n
    Service:<\/p>\n\n\n\n
    @RunWith(SpringRunner.class)\npublic class BookServiceTest {\n\n    @InjectMocks\n    private BookService bookService;\n\n    @Mock\n    private BookRepository bookRepository;\n\n    @Test\n    public void findByIdTest() {\n        Book book = new Book(1L, \"Test Title\", \"Test Author\");\n        when(bookRepository.findById(1L)).thenReturn(Optional.of(book));\n\n        Book foundBook = bookService.findById(1L);\n\n        assertEquals(book.getTitle(), foundBook.getTitle());\n    }\n\n    @Test\n    public void createBookTest() {\n        Book book = new Book(1L, \"Test Title\", \"Test Author\");\n        when(bookRepository.save(any(Book.class))).thenReturn(book);\n\n        Book savedBook = bookService.createBook(book);\n\n        assertEquals(book.getTitle(), savedBook.getTitle());\n    }\n}\n<\/code><\/pre>\n\n\n\n
    Repository:<\/p>\n\n\n\n
    @RunWith(SpringRunner.class)\n@DataJpaTest\npublic class BookRepositoryTest {\n\n    @Autowired\n    private TestEntityManager entityManager;\n\n    @Autowired\n    private BookRepository bookRepository;\n\n    @Test\n    public void findByIdTest() {\n        Book book = new Book(1L, \"Test Title\", \"Test Author\");\n        entityManager.persistAndFlush(book);\n\n        Optional<Book> foundBook = bookRepository.findById(1L);\n\n        assertTrue(foundBook.isPresent());\n        assertEquals(\"Test Title\", foundBook.get().getTitle());\n    }\n\n    @Test\n    public void saveBookTest() {\n        Book book = new Book(1L, \"Test Title\", \"Test\n<\/code><\/pre>\n\n\n\n
    As you can see, this is a lot of test code.  This code has to be maintained just the same as the functional code.  Additionally, the use of mocks hardens the interfaces between classes, making changes between classes difficult because of the cascading changes to the tests that will result.  This might<\/em> be desired in a mature system, but the reduction in flexibility is usually not desired.<\/p>\n\n\n\n
    The  Advantages of Component Tests<\/h2>\n\n\n\n
    Component tests (also called integration tests) look at groups of components or the whole system. They’ve got some advantages over unit tests:<\/p>\n\n\n\n
      \n
    1. Real-life scenarios: Component tests show you how the system works in the real world, so you get a better idea of how components interact and what the overall behavior is.<\/li>\n\n\n\n
    2. Better integration coverage: By testing components together, you can find issues that unit tests might miss, like data flow, communication, or dependency management problems.<\/li>\n\n\n\n
    3. Less brittleness: Since they focus on the big picture instead of tiny details, component tests are less likely to break when you change the code.<\/li>\n\n\n\n
    4. Efficient testing: Sometimes, component tests can give you better test coverage with fewer tests. That means less maintenance and an easier time finding problems.<\/li>\n<\/ol>\n\n\n\n
      Here’s example tests that should cover the same functionality as the unit tests:<\/p>\n\n\n\n
      @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)\nclass BookControllerComponentTest {\n\n    @Autowired\n    private WebTestClient webTestClient;\n\n    @Autowired\n    private BookRepository bookRepository;\n\n    @AfterEach\n    public void tearDown() {\n        bookRepository.deleteAll();\n    }\n\n    @Test\n    void getBookByIdTest() {\n        Book book = new Book(1L, \"Test Title\", \"Test Author\");\n        bookRepository.save(book);\n\n        webTestClient.get()\n                .uri(\"\/book\/{id}\", book.getId())\n                .exchange()\n                .expectStatus().isOk()\n                .expectBody()\n                .jsonPath(\"$.title\").isEqualTo(book.getTitle())\n                .jsonPath(\"$.author\").isEqualTo(book.getAuthor());\n    }\n\n    @Test\n    void createBookTest() {\n        Book book = new Book(1L, \"Test Title\", \"Test Author\");\n\n        webTestClient.post()\n                .uri(\"\/book\")\n                .contentType(MediaType.APPLICATION_JSON)\n                .bodyValue(book)\n                .exchange()\n                .expectStatus().isOk()\n                .expectBody()\n                .jsonPath(\"$.title\").isEqualTo(\"Test Title\")\n                .jsonPath(\"$.author\").isEqualTo(\"Test Author\");\n\n        \/\/ Fetch the book from the database\n        List<Book> books = bookRepository.findByTitle(\"Test Title\");\n\n        \/\/ Validate that the book was correctly saved\n        Assertions.assertFalse(books.isEmpty(), \"No books found\");\n        Assertions.assertEquals(book.getTitle(), books.get(0).getTitle());\n        Assertions.assertEquals(book.getAuthor(), books.get(0).getAuthor());\n    }\n    }\n}\n<\/code><\/pre>\n\n\n\n
      In this case, the @SpringBootTest annotation instructs Spring Boot to launch your application, including creating the ApplicationContext and starting the server.<\/p>\n\n\n\n
      We’re using WebTestClient<\/code> instead of MockMvc<\/code> to perform HTTP requests, and we’re using @Autowired<\/code> to get an instance of our BookRepository<\/code> to setup and tear down our data for each test.<\/p>\n\n\n\n
      Please note that these component tests will run slower compared to unit tests as they are loading the entire application context and not just a slice of it. Also, they would need an actual database connection to run, as opposed to the mocked repository in unit tests.<\/p>\n\n\n\n
      Personally, I use H2 as a quick and dirty in memory database for testing.  Here’s how you could set it up for this example
      <\/p>\n\n\n\n
      First, add H2 dependency in your pom.xml<\/code> file:<\/p>\n\n\n\n
      <dependency>\n    <groupId>com.h2database<\/groupId>\n    <artifactId>h2<\/artifactId>\n    <scope>test<\/scope>\n<\/dependency><\/code><\/pre>\n\n\n\n
      Then, you need to create a application-test.properties<\/code> file in your src\/test\/resources<\/code> directory. This is where you’ll specify the configurations for your H2 database. Here’s what that file might look like:<\/p>\n\n\n\n
      spring.datasource.url=jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE\nspring.datasource.driverClassName=org.h2.Driver\nspring.datasource.username=sa\nspring.datasource.password=\nspring.jpa.database-platform=org.hibernate.dialect.H2Dialect\nspring.jpa.hibernate.ddl-auto=create-drop\nspring.h2.console.enabled=true<\/code><\/pre>\n\n\n\n
      In this file, we’re configuring Spring Boot to use an in-memory H2 database for the data source and Hibernate to automatically create and drop the database schema.<\/p>\n\n\n\n
      Finally, you need to tell Spring Boot to use this profile during testing. You can do this with the @ActiveProfiles<\/code> annotation in your test class:<\/p>\n\n\n\n
      @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)\n@ActiveProfiles(\"test\")\nclass BookControllerComponentTest {\n    \/\/ ...\n}<\/code><\/pre>\n\n\n\n
      Yes, there’s a little bit more configuration (for the test environment), but the test code is extremely<\/strong> small.  Additionally, the test code tests the interface of our service only (the REST endpoints) which tests the behavior we care about with a high level of coverage.<\/p>\n\n\n\n
      Striking the Perfect Balance for Software Quality<\/h2>\n\n\n\n
      The best approach to software testing involves using both unit tests and component tests. Unit tests are great for testing individual functions or components in isolation, while component tests make sure that the system works as expected when all its parts are put together. By combining these testing strategies, developers can achieve a more comprehensive and reliable assessment of their software’s quality.<\/p>\n\n\n\n
      For our Spring Boot example, we can further enhance the application by adding more features like update and delete book. To maintain software quality, we would create both unit tests and component tests for each new feature. This way, we can ensure that the individual components work correctly in isolation and that the system as a whole functions as expected.<\/p>\n\n\n\n
      Conclusion<\/h2>\n\n\n\n
      Understanding the strengths and weaknesses of unit tests and component tests is crucial for any software development project. By carefully considering the benefits and drawbacks of each approach and using a blend of both testing strategies, developers can create software with enhanced quality, functionality, and reliability.<\/p>\n\n\n\n
      With a solid understanding of both testing methodologies, developers can make informed decisions and create robust, reliable software. Remember, the key is to strike a balance between the two testing approaches to get the best of both worlds for top-notch code quality.<\/p>\n\n\n\n
      This is my ultimate recommendation:<\/p>\n\n\n\n