问题
I don't mean defer all unit-testing until an integration test passes. The unit tests I'm referring to are those that verify that the SUT interacts with the 3rd-party mystery API correctly.
The rationale for deferring these unit tests is that they verify something that is unknown. If I don't know how the 3rd-party mystery API works, how can I even write a unit test to ensure that the SUT uses the 3rd-party API correctly? Only once some minimal integration tests pass do I actually know what behavior to verify.
Of course, all other unit tests should be written before the SUT is written in the usual way (red, green, refactor).
回答1:
Under the assumption that it's an external api I'd argure that your tests probably wouldn't qualify as a unit test anyway. They'd be integration tests.
How about writing a mock to test your code as is and then writing proper integration tests when you can access the 3rd party api? Also, if you're unit testing third party stuff, then your build will fail as soon as those things are unavailable which might be a problem in the long run.
回答2:
A few years later, I have done much more unit testing, and feel I understand this better. Unit tests are good at verifying that a piece of code is correct ASSUMING that you correctly understand how to use the API's that are faked (mocked / stubbed). But to fake out those API's correctly, you must first understand how they work. So after reading the documentation for those API's, you can check your understanding by doing a proof-of-concept--even if that means testing code manually after writing it--or by writing an integration test. Once you are semi-comfortable with your understanding of the thrid-party API, you can fake it in a unit test and follow TDD once again.
Wrappers for third-party API's are an excellent thing to write integration tests for, where you merely test your minimal wrapper without faking the third-party API to ensure you correctly understand it. Some of these tests might not really be tests, but demonstrations written like tests. They come in handy later, too, because you can review them if you forget how something works, help a coworker understand the API, and discover subtle breaking changes when you upgrade the API.
Today, I often write integration tests of wrappers, write demonstrations / examples of third-party API's exercising corner cases relevant to my situation, and even write production code and manually test it if I have to. I only have to when there is an ambiguity or unclarity in the API I'm using. Once I feel confident about how to use it, it's time for "normal" TDD.
来源：https://stackoverflow.com/questions/3406865/is-it-wise-to-defer-unit-testing-until-integration-tests-pass-in-scenarios-where