Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In my humble view of unit testing a unit test tests a single unit of code. For me, this means a single class. Every dependency for that class is mocked in the corresponding test class, and passed in the constructor (or injected via a DI container). This allows you to test the class in complete isolation from the rest of the system. I take this as the gospel truth of what a unit test is supposed to be. If you are testing multiple real classes (more than one class in your test class is not a mock) then you don't have a unit test, you have an integration test.

Given this point of view, there are things that seem to fall outside of the realm of unit testing even though it seems as if you are testing a single class. One of these types of tests is data parsing tests. For example, given a data class:

public class Person {
  private Name name;
  private PhoneNumber phoneNumber;
  private Address address;
}

a purported unit test then attempts to validate correct parsing:

@Test
public void shouldParsePerson() {
    String json = "{ the json would be here }";
    Person person = new Gson().fromJson(json, Person.class);

    assertThat(person.getName().getFirst()).isEqualTo("Jim");
    // more assertions based on what the JSON was would be here
}

What is this really testing? For me, it appears to be testing that Gson works. The test is tightly coupled to both the structure of the JSON and the class in Java that it maps to. Is the test really worth writing? Is it worth maintaining? Is it useful? Wouldn't an integration test somewhere else that relies on the parsing code catch this anyways?

There is another question here that is related to my question, but it is actually different because it is asking how to unit test consumers of an API that wraps third parts classes, while I'm asking what constitutes a valid unit test that involves a third party class. My question is more philosophical in nature, while the other is more practical. My question could also be extended to things like testing configuration code which isn't necessarily involving third party classes.

share|improve this question
1  
The only thing it could be testing - If Gson() mandates, toString(), equals() or hashCode(). –  TJ- Mar 18 at 18:32
    
    

1 Answer 1

up vote 6 down vote accepted

In general, unit testing should test your code, not the code of some library. Presumably the library already contains its own unit tests.

Certainly, one or two unit tests would help you get the feel of the library and how it works. But detailed testing of this kind generally falls under the purview of integration testing.

share|improve this answer
    
That's what I thought. Just need some validation from some people outside of myself so I can get this into our coding standards. –  Christopher Perry Mar 18 at 18:33
    
Unit testing json structure is useful when you start using custom formats and not just what the library provides –  Leon Mar 18 at 19:59
1  
@Leon: Yes, to verify that your JSON structure is correctly formed. I imagine that an error like that would be identified in the integration tests, though. –  Robert Harvey Mar 18 at 20:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.