# Write that first complicated test

DevFeed: [Write that first complicated test](<https://devfeed.tech/articles/write-that-first-complicated-test-26279.md>)

Original publisher: [Read original article](<https://www.justinweiss.com/articles/write-that-first-complicated-test/>)

Author: Justin Weiss

Published: 2017-03-01T05:05:56Z

Content type: tutorial

Language: en

Sources: [Justin Weiss](<https://devfeed.tech/sources/justin-weiss.md>)

Topics: [Testing](<https://devfeed.tech/topics/testing.md>), [unit test](<https://devfeed.tech/topics/unit-test.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>), [Git](<https://devfeed.tech/topics/git.md>), [networking](<https://devfeed.tech/topics/networking.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [ui](<https://devfeed.tech/topics/ui.md>)

Tags: [also](<https://devfeed.tech/tags/also.md>), [code](<https://devfeed.tech/tags/code.md>), [git](<https://devfeed.tech/tags/git.md>), [integration-test](<https://devfeed.tech/tags/integration-test.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>), [unit-test](<https://devfeed.tech/tags/unit-test.md>)

## AI overview

This article explains how to approach testing complicated code involving threads, commands, Git, networking, or user interfaces. It recommends investing in fakes, mocks, fixtures, and test-specific configuration, and using integration tests as a practical starting point when fast unit tests are difficult to write.

## Source excerpt

What code of yours isn't tested? Is it code that deals with complicated situations that you don't control? Threads, running commands, git, networking, or UI? Our apps are most interesting when they're complicated. They're also most dangerous. And that's why code that's hard to test is exactly the kind of code that needs to be tested well. That doesn't always happen. Instead, every time you touch that code, you touch lightly. You tread carefully. Maybe you do some manual testing. And when you send the pull request, you hope your teammates don't realize those tests don't exist. But that won't make things better. You'll run into the same problems, the same bugs, the same stress next time - and every time after that. How can you finally make those challenging tests something you can rely on? Shift your mindset The most frustrating thing about these tests? It's going to take ten times as long to write it as it feels like it should. If you estimate the time the test saves you against the time you spend writing the test, it just doesn't seem worth it. But it's not just about this test. It's about all your future tests. Most of the best-tested code I've seen has a lot of support. It's not just the code in test/models. Extremely well-tested code has fakes, it has mocks, it has a good set of test fixtures, it has configuration options specifically for the tests. All that takes time to write and put together. But once you have it, it feels so good. You can come up with test after test, feeling comfortable about your code, and confident in quickly you can move after the investment you've made. You can rely on the work you've already done. So it's not just about preventing bugs in complicated code. It's also about making future code easier to test, piece by piece. Make it an integration test (for now) Sometimes, though, it's not about understanding the value - I get it. Instead, I just get stuck because I can't figure out how to write a small, fast, unit test. How do you know yo