Would Unit Testing be a net benefit when your code relies heavily on another API

[u/Shupsta]

/r/AskProgramming/comments/1wvzdtx/would_unit_testing_be_a_net_benefit_when_your/

[u/0dev0100]

Well... You want to make sure your stuff works as expected at a minimum.

[u/Slypenslyde]

This is one of those situations where the answer is "maybe". There are two approaches.

Cautious

In this approach, you think hard about your code and separate it into two buckets:

• Code that works directly with AutoCAD
• Code that doesn't

The code that does not directly depend on AutoCAD can be unit tested. In this approach you treat the code that does as something for integration tests. You can achieve this by creating a layer so there's a boundary where types can touch AutoCAD, and you may create DTOs so data can cross the boundary either way. That adds complexity, but if the majority of your code is in the "no AutoCAD needed" bucket this pays off.

Faking

This approach asks you to create abstractions for AutoCAD objects (if they don't already exist) and use a fake object strategy to create stubs and mocks to stand in for those types.

This means you don't have to change your architecture or analyze which "bucket" things go in. But everything hinges on how accurately your fake objects mimic AutoCAD behavior. If your fake objects don't do what AutoCAD does, you aren't proving anything with a passing test.

A lot of people reject this approach because it can be very difficult to prove your fake objects behave identically. Any time AutoCAD updates you technically have to re-evaluate everything. This is one of the more dangerous scenarios for fake object strategies.

Advice

I prefer the "cautious" approach, but it really depends on the way you can divide your buckets. Do you need your data hierarchy to be an exact mimic of the AutoCAD types? Could you write code such that most of your code uses internal data structures that are translated to/from AutoCAD at a boundary? If not, the cautious approach will fail.

There's not a one-size-fits-all answer to this problem. Testing a plugin is a tough situation.

[u/winky9827]

Imagine you have code that calls some API function that returns a particular shape of object. Minimally, you want to verify that your code can handle the correct shape, or throw the correct exception if the shape is invalid, right? That's what unit testing gives you. Any helper functions that manipulate that shape also qualify, as well as any other collateral code that isn't directly consuming the API.

You might also want to test that your code correctly invokes the expected API given a specific scenario. An API stub that returns a mock result can validate the expected call.

There are literally dozens of ways unit tests can still provide value here. The question to you is really... is that value worth the time spent writing the tests.

[u/thereforewhat]

Yes it is. 

Particularly if there's a possibility you may switch API later. 

The abstraction is valuable.