-3

We have built a library which can handle RESTful requests based on configured endpoints.

  1. A fluent builder is being used to create endpoint definitions (configurations). These definitions are bound to a request.
  2. When a request is being executed, the definition is being used to set the correct parameters, like HTTP headers, the HTTP body and so on.
  3. Before executing the request, there is a check if the request should be cached or retrieved from a cache, the cache requirement is also stored in the endpoint definition mentioned in point 1.

Fellow developers are worried about the testability of this setup. Because:

  • The configuration is being built up using a builder, to test if the configuration is set correctly, the HTTP requests which are the result of the configured endpoint need to be validated (are the header settings and so on being translated/passed correctly).The configuration resides in another library and is made not public, since it is not being accessed from the library from which the tests are running.
  • The caching configuration needs to be tested, because my fellow developers want to be sure the right things are being cached according to their configuration.

These are all valid concerns, so how to test the configuration in combination with with the builder?

My option would be to mock all dependencies and make a bunch of unit tests.

Improve this question
6
  • can you explain why its a problem to write unit tests? Commented Mar 25, 2024 at 17:12
  • @Ewan because the builder results in configuration objects which are defined in another library. The developers want to be sure the configuration is correct. Commented Mar 26, 2024 at 7:10
  • 2
    why is it hard to test the result is as expected? Commented Mar 26, 2024 at 8:59
  • @Ewan at least you take the time to ask questions to clarify instead of downvoting a question you don't understand. Because the builder results in a definition structure which immediately gives 100% code coverage because the definitions are in another library. They are worried about changes in configuration not being caught. But the more I think about it, the more I think this is a non-issue, because the code which handles the passing of the configuration is already being tested (code coverage is 95%) in the library itself. The upstream library does not have to test that again. Commented Mar 28, 2024 at 9:36
  • I still don't understand and I think this is why you are getting downvotes. We've all made builders they can have some unique testing challenges with hidden info and stuff. I can see that the built result might be a class from another library. I dont see why you cant just have actual = builder.AddThing(); Assert actual.Thing == expected Commented Mar 28, 2024 at 10:19

1 Answer 1

Reset to default
0

Test the artifact of construction.

If you want to test that text was parsed correctly make the parsed data structures testable.

Mocking dependencies should mostly be reserved for dependencies that keep a test from being deterministic, parallelizable, and fast. Typically that means no IO in the unit under test. It certainly doesn’t mean you can’t use builders to create what the test needs.

It may mean the unit under test needs to be rewritten to be testable. IO should not be required to see results.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.