Unit tests for a simple function thats part of a public API Given I have to write a simple function that essentially just does a http-fetch
 to the given URL but is part of a public API that will be used by thousands. 

I have two main questions about the problem:


Since this is a public API Im not sure how to handle inproper input. Should I return undefined or throw an error? (I rather throw errors to make it most obvious what types are expected). I've seen other API's however just returning undefined, which to me seems pretty stupid, as surely you dont want to be handling undefined in high level code?

function at(_url, _options) {

    if (!_options)
        throw new ReferenceError("No options provided.")

    if (typeof _options !== "[Object object]")
        throw new TypeError("No options provided.")

    if (typeof _url !== "string")
        throw new TypeError("URL must be a string.")

    ...

Is it too much to actually test if each possible inproper input is at hand?
(I find myself writing the same test code for each function I write and after a while it seemed kind "wrong" to be doing typechecking in JS. Is there a standard for typechecking inside API's in JS?)

const expect = require("chai").expect
const fetchWithOptions = require("./../index")

describe("me()", () =&gt; {
    it("should throw error if no options are provided", () =&gt; {            
        expect(() =&gt; fetchWithOptions.at("some-url")).to.throw(ReferenceError)
    })

    it("should throw an error if options are not an object", () =&gt; {
        expect(() =&gt; fetchWithOptions.at("some-url", "string options")).to.throw(TypeError)            
    })

    it("should throw an error if the provided url is not a string", () =&gt; {
        expect(() =&gt; fetchWithOptions.at(123123, {someOption: "someOption"})).to.throw(TypeError)                        
    })

})
Assuming this function is async, neither. Provide a callback parameter or return a Promise (I'd favour Promises personally). This is a more common / understood pattern in JavaScript.
Unfortunately no there isn't, it's very much part of the downsides (and beauty) of using a loosely-typed language. If you're concerned about type-safety then you should really take a look at TypeScript or equivalents.


With regards to the tests, personally I think covering each error scenario is fine - I do it myself, they're minimal effort and will help catch any regressions.