When to Write Unit Tests vs Integration Tests

Рет қаралды 1,063

9 күн бұрын

It can be hard to know when to write unit tests vs. integration tests, so today I’ll break down the difference between the two and explain in what cases each works better.
Deliberate Practice Repo: github.com/seniorcodereviewbu...
The outro music is:
Funk Game Loop by Kevin MacLeod is licensed under a Creative Commons Attribution 4.0 license. creativecommons.org/licenses/...
Source: incompetech.com/music/royalty-...
Artist: incompetech.com/

Пікірлер: 12

@0xO2 6 күн бұрын

The key phrase is "you think". When you think wrong about a thing then you may make same mistake in both code & unit test. IMHO unit test are useful only if you implement some QA's test case for that unit. Also refactoring will require change in related unit tests, which is additional time burden. Integration tests OTOH must not change in case of refactoring. Only if version of the interface or API is changing due to big rewrite, but not small refactoring of the units.

@SeniorCodeReviewBuddy 4 күн бұрын

"When you think wrong about a thing then you may make same mistake in both code & unit test." That is very true and it has bitten me a few times in a past for sure. And I do think this is also why it can be helpful to try and write at least some of the unit tests first, so you (hopefully) aren't thinking too much about how exactly you solved the problem.

@AJenbo 5 күн бұрын

I prefer Feature Test: Test that business logic works in accordance with the given specs. Use Unit Test for complex/critical logic units, and Integration Tests to test that destintct systems (API calls) are able to communicate, basically things that you cannot necessarily have available locally or are simply to slow to spin up/test. P.s. nice to see some typed Python

@ismaely.racine4866 4 күн бұрын

Is "Feature Test" another term for "Integration tests" ? Here are the terms I heard, and struggle to reconcile: 1. Unit tests (this one is easy) 2. Integration tests 3. Implementation tests 4. Regression tests 5. Acceptance tests 6. Feature tests 7. End-to-End tests Are the points 2-6 more or less the same "level" of testing with different goals in mind? (by the same "level" I mean you're testing more than one file, so some sort of mocking needs to take place)

@AJenbo 4 күн бұрын

@@ismaely.racine4866 in my message I tried to lay clear the difference between unit, feature and integration. So I'm not sure why you think they might be the same. I see them as 3 levels, feature test test a full feature in the system, but all external dependencies (APIs, DB, etc) are mocked, nothing can fail because of network faults or external changes. They should run fast, and be run with every change. Unlike unit tests they do not care about implementation rather they are about a consume facing feature that the system should be able to satisfy. Intetgration testes are different in that they do not mock externals, can be slow and may periodically fail despite no changes to the system. Unit test: test that IsHoliday() returns true for Thanks Giving. Feature test: test that the confirmation page has the correct information (products, delivery eta, etc) when simulating an order Intetgration test: check that the shop correctly calls the ERP system to check for real time stock

@AJenbo 4 күн бұрын

1. Unit tests: Despite you saying it's easy lots of people actually gets this one wrong and test several things and not just a single code unit. If your understanding does not reflect this other types of test can seem confusing. 2. Integration tests: Test the system in a state as close to production as possible. 3. Implementation tests: I'm unfamiliar with this term. 4. Regression tests: They are more like unit tests, you create one each time you fix a bug to make sure it doesn't happen again. After all your othere tests where not good enough to prvent it in the first place. 5. Acceptance tests: In software development this is often very similar to what I refere to as feature tests. 7. End-to-End tests: This is what I would say is the same as intergration tests, but there are differing definitions.

@SeniorCodeReviewBuddy 4 күн бұрын

@@AJenbo I think that's a pretty good write up of the terms. I've seem them all very from place to place, but this seems like a good starting point. One thing I'd suggest/say, is that in my opinion regressions tests generally shouldn't exists. The fact that you found it because a bug previous slipped through doesn't mean it should be a different test, regression tests should just be regular unit tests/integration tests/etc, only the change log should reveal how they were discovered. Although I'll totally agree with using "regression tests" when referring to ensuring certain APIs and the like still work with older versions that are being supported

@ismaely.racine4866 4 күн бұрын

Thank you very much for this video! I am relatively new to web development, and I do feel like my learning is going well, but I am stuck in "analysis paralysis" hell when it comes to testing, ***especially when it comes to testing the front-end***. There are so many libraries, so many different concepts that it's hard to figure out exactly *which* parts of your code to test, and *what* type of tests are best suited for your use case. I'm also not a fan of 100% code coverage, as I do not think it's an adequate measure to improve software quality; it seems pointless to write tests that will be more costly to maintain than the time they would save during refactoring, or if a bug were to arise. In this regard, the only use cases of automated tests I understand for the moment are as follows: 1. Unit tests: for business logic, they have value when they're written before or during the coding of the tested feature. 2. End-to-end tests: validate the most common, the most important, and the most fragile flows of your app. They have value in any application that is more than trivial. I really struggle to see the value of integration tests specifically because of the mocking. I have been burned before with slight differences in development environments changing the expected behaviour of some code, enough that I have no confidence a mocked Service within a test framework will behave the exact same way as its counterpart deployed in a staging environment. On top of that, integration tests require the most punctual maintenance, as you need to manually modify the tests each time a dependency is added, removed, or modified. E2E tests, while they might be orders of magnitude slower, at least provide you with the confidence that the tests were run on the environment it meant to test, instead of on an environment that's sorta-kinda the same. Here is my question: is there any benefit to integration tests over E2E tests, besides speed of execution? Sorry for the long preamble btw, I tried to keep it short but obviously failed

@SeniorCodeReviewBuddy 4 күн бұрын

Thanks for the comment and watching! Getting burned by code changing when mocks aren't changed isn't fun at all. I do think integration tests have some additional benefits over e2e in addition to speed, and the one I'd call out is code simplicity. With the integration tests (in theory) you're able to have more focus on the code you've written, as you don't need as much code (or knowledge) dedicated to the systems you are interacting with. So the integration tests are probably easier to read and understand then equivalent e2e tests would be. And that can also be helpful for letting you know where the issue is. While e2e tests are great at saying something is broken (which is very important to the end user), they are less good at saying what is broken and where the fix will be, and integration tests can help fill that gap.

@AJenbo 4 күн бұрын

@@ismaely.racine4866 integration tests can also be very helpful when doing refactoring/maintenance. Since they should not care about the implementation and allow you to quickly and reliably find functionality that do not behave the same as before. Having mocks that do not behave like the real thing sounds like the issue is that the interface the system you are talking to is not well defined. It can help to capture fixtures from the real thing, but if it's a moving target with no set interface then I would say the real problem is that who ever is making that service are not doing a good job of defining an interface and testing that they comply with there own specs.

@ismaely.racine4866 3 күн бұрын

@@SeniorCodeReviewBuddy Thank you very much for your reply! > With the integration tests (in theory) you're able to have more focus on the code you've written, as you don't need as much code (or knowledge) dedicated to the systems you are interacting with. Are you saying the e2e tests, in comparison, tend to require more code to write, or more mocking? Because I think e2e tests can still be code-split intuitively. It's simply of a matter of adopting and sticking to a convention, no? I feel like I might be confusing the different properties of testing, specifically "white-box" vs "black-box", and "integration" vs "e2e" vs [...]. Maybe what I'm advocating for is more of a black-box approach, whereas the *type* of the test is more dependent on the context? Because I definitely see why you wouldn't want to test the entire Thank you again for your time!

@SeniorCodeReviewBuddy 12 сағат бұрын

@@ismaely.racine4866 When I think of e2e tests, I generally think of no mocking. When there is mocking, I generally think it's more an integration test. So this means that in an integration tests, with mocks, you can just say what the values the mocked systems should return. In an e2e test, you'd need to setup and initialize all systems to return the correct values. So from the point of view of just testing system X, a higher percentage of the integration test code will be related to system X, because the e2e test has to setup other stuff. So while the e2e test is very important, and helps to ensure every thing works together, the integration tests can be more focused on helping you figure out the individual pieces are working. It also can make it clearer where the failure is, since with a e2e failure, in theory, the problem could be any part of the process. (more code to look at). Hopefully that makes sense :) >I feel like I might be confusing the different properties of testing, specifically "white-box" vs "black-box", and "integration" vs "e2e" vs [...]. Maybe what I'm advocating for is more of a black-box approach, whereas the type of the test is more dependent on the context? I think you've got this. I'd generally say tests should be black-box (testing the API, not the implementation), but integration vs e2e vs unit is more about the level being tested.