1

I'm asking myself above question since I implemented an API that accesses a third-party API and currently write tests to increase my code coverage in the class that communicates with the third-party API. Currently I'm sitting at 76.6%. I covered possible third-party API-responses and JSON parsing errors.

What's left are parts of the code that are not influenced by user input. For example:

url := "some url here"
method := "GET"

payload := strings.NewReader(`{ }`)

client := &http.Client{}
req, err := http.NewRequest(method, url, payload)
if err != nil {
    fmt.Println(err)
    return "", err
}

Basically no matter what happens this code should not fail at any point any quite frankly I do not know how I can make this part of the code fail on purpose in a test. Should i just let this partt of the code go uncovered or what would be my best option?

hullunist
  • 137
  • 2
  • 4
    Does this answer your question? [Where is the line between unit testing application logic and distrusting language constructs?](https://softwareengineering.stackexchange.com/questions/322909/where-is-the-line-between-unit-testing-application-logic-and-distrusting-languag) – gnat Mar 18 '21 at 13:46
  • What if string.NewReader fails ? What if client := &http.Client{} fails ? The probability is low but it can happen. – f222 Mar 18 '21 at 14:43
  • 2
    Why do you think GETting a URL can never fail? Does the server you connect to _never ever_ go down? – FrustratedWithFormsDesigner Mar 18 '21 at 14:53
  • 3
    I am very very suspicious of the value of chasing artificial coverage targets ... but that doesn't mean there aren't useful tests that can be written for this code. – IMSoP Mar 18 '21 at 16:09

1 Answers1

8

Yes - tests are there to demonstrate the code behaves the way you expect. There is no such thing as cannot fail in code.

You should write tests to demonstrate the code performs the task it is supposed to. Code can always fail. Testing demonstrates functionality under controlled, repeatable conditions. If the code can truly not fail then you should be able to demonstrate that via tests.

Functions get reused through-out the code base and modified to fit the new need. How can you show the enhanced functionality still meets the original spec - testing!

I don't know why you said your code cannot fail. It involves an HTTP call. Those can fail - it's part of the standard.

Your code can currently fail in a myriad of ways.

EDIT - how it can fail? 404s, and plenty more

This code calls an HTTP endpoint. What happens if it gets a 404, or any number of other valid HTTP errors? What happens if the endpoint takes a long time to respond? What happens if it gives you back an empty string? A string you can't parse?

But I can't call the API in a test

Then Mock the HTTP framework and test for 404s, long calls, and other error conditions.

But that's not testing the actual API endpoint

You're right - it's testing your code that takes the response and processes it. You could also add an integration test which calls some non-destructive API call for real to make sure you can access it.

The goal of testing is to demonstrate that from single function calls to massive integration of multiple packages, APIs, and contributors your product does what it's suppose to do.

sevensevens
  • 368
  • 1
  • 5
  • This answer is mainly a pitch for unit testing. Without a suggestion or two about **what can actually fail**, and what therefore should be tested, this answer is not very useful. – user949300 Mar 18 '21 at 15:28
  • 2
    @user949300 - expanded to address a few examples of how it could fail. The OP assumes his code can't fail because there is no user input, which is a VERY faulty assumption. – sevensevens Mar 18 '21 at 16:27
  • 2
    @user949300 A very common way for code to fail is for a developer to make a mistake at some point in the future which leaves a regression issue. With thorough automated testing, there's a decent chance that it'll be picked up straight away. Without automated testing it's mostly down to luck as to whether a human reviewer or manual tester might just happen to test the right use case to identify the problem. Otherwise, it'll be an end-user who finds the problem after the code is released into production. – Ben Cottrell Mar 18 '21 at 20:30