All types of testing are necessary.Less end to end integration testing for sure. Unit testing rigorously test logic or validations of the unit. Work for a healthcare SUT , we have 3500 unit tests , but we always find bugs on integration part.
Great vid :) One part I can't seem to understand is how to properly write an integration test when the flow contains operations with side effects. I find that frequently in enterprise coding, with the exception of blatantly silly bugs, most mistakes come from some unexpected behavior in mutable modules. So I feel like writing an integration test that "ignores" or by-passes some of these key operations renders the test itself almost useless, since it does not simulate real life behaviour
I disagree. I think both unit and integration tests are essential. Unit to prove to the developer that this unit actually does what the developer thinks it should do and integration to prove that the application does what it is required to do. Saying that integration tests are a bad idea because of the large combinations that would need to be tested is at best an unwitting strawman. There are different types of integration tests with their own distinct values. I personally take outside in approach with HIGH unit test coverage. I don't need to test all the of different paths a code takes in integration testing. I just need to test if the requirement works. If the requirement is display a blue banner for the user when he/she is over 21 then that's what the test will do. I don't care about what the person factory returns. I don't care if I'm dealing with a BabyPerson, InfantPerson, TeenagePerson, AdultPerson, MiddleAgePerson, or SenilePerson object. I have unit tests for those and all I care about is any person over 21. At runtime the type will likely be AdultPerson, MiddleAgePerson, or SenilePerson but that's not what the requirements say. The requirements are made by people who couldn't care less about how you implemented the person object model or what an object model is.
Agree and I would add that "unit tests" should actually be considered part of development (because unit tests inform and channel development itself). People in charge of systems in an enterprise setting know that anyone saying "integration testing is a scam" is certified insane or out of his depth and should be removed from premises. Integration tests shall and must run, every day, all day!
I mostly disagree. Absolutes like this are rarely correct in computer science. In an ideal world, integration testing drives the coverage and completeness of unit testing.
I disagree as well cause I usually write only spring integration tests. Your examples are non-realistic. My example is: rest-controller with method GET /api/tickets?startDate=2023-02-27&endDate=2023-03-05. Complexity is definitely huge, cause negative scenarios might be in all tiers: controller, service, repository. But evolving requirements might shift our logic into repository (QueryDsl) just to improve performance of selects, joins, views etc. If we had 3 test classes for each tier that would not simplify our work cause we would need to remove some tests from service layer into repository layer test and then adapt them to mocks of your testclass. On the other hand having robust MockMvc tests that shoot through all three layers would not need any modifications - and we are free to perform our refactoring. I state that ease of future refactoring is main benefit of TDD.
Sir I am an QA engineer in india.i am using selenium automation tool.i don't know how to do integration testing using automation code.sir can you please share me one video for that integration testing.
I think should be relation of 1 to 10 or even more for Integration Tests Vs Unit Tests. The problem I see is that some developers only use Integration tests. As a TDD practitioner my coverage is normally high and use Integration tests just to examine the code works correctly. Also perform some pair testing with QA just to explore alternative scenarios. Also a good strategy is to create a general end to end test for every acceptance criteria and apply double TDD feedback loop.
All types of testing are necessary.Less end to end integration testing for sure. Unit testing rigorously test logic or validations of the unit. Work for a healthcare SUT , we have 3500 unit tests , but we always find bugs on integration part.
I love conversations about code. Where else will you hear "When we are integrating with the fish..."?
If all you're testing is that the parts are integrated properly, then your combinatorics explodes significantly slower.
Great vid :)
One part I can't seem to understand is how to properly write an integration test when the flow contains operations with side effects. I find that frequently in enterprise coding, with the exception of blatantly silly bugs, most mistakes come from some unexpected behavior in mutable modules. So I feel like writing an integration test that "ignores" or by-passes some of these key operations renders the test itself almost useless, since it does not simulate real life behaviour
I disagree. I think both unit and integration tests are essential. Unit to prove to the developer that this unit actually does what the developer thinks it should do and integration to prove that the application does what it is required to do. Saying that integration tests are a bad idea because of the large combinations that would need to be tested is at best an unwitting strawman. There are different types of integration tests with their own distinct values. I personally take outside in approach with HIGH unit test coverage. I don't need to test all the of different paths a code takes in integration testing. I just need to test if the requirement works. If the requirement is display a blue banner for the user when he/she is over 21 then that's what the test will do. I don't care about what the person factory returns. I don't care if I'm dealing with a BabyPerson, InfantPerson, TeenagePerson, AdultPerson, MiddleAgePerson, or SenilePerson object. I have unit tests for those and all I care about is any person over 21. At runtime the type will likely be AdultPerson, MiddleAgePerson, or SenilePerson but that's not what the requirements say. The requirements are made by people who couldn't care less about how you implemented the person object model or what an object model is.
Agree and I would add that "unit tests" should actually be considered part of development (because unit tests inform and channel development itself). People in charge of systems in an enterprise setting know that anyone saying "integration testing is a scam" is certified insane or out of his depth and should be removed from premises. Integration tests shall and must run, every day, all day!
ua-cam.com/video/VDfX44fZoMc/v-deo.html
Can’t we use test design techniques to pick a set of tests to do integration?
Big bang integration testing seems to be pretty handy for small 1 man projects.
I mostly disagree. Absolutes like this are rarely correct in computer science. In an ideal world, integration testing drives the coverage and completeness of unit testing.
I disagree as well cause I usually write only spring integration tests. Your examples are non-realistic. My example is: rest-controller with method GET /api/tickets?startDate=2023-02-27&endDate=2023-03-05. Complexity is definitely huge, cause negative scenarios might be in all tiers: controller, service, repository. But evolving requirements might shift our logic into repository (QueryDsl) just to improve performance of selects, joins, views etc. If we had 3 test classes for each tier that would not simplify our work cause we would need to remove some tests from service layer into repository layer test and then adapt them to mocks of your testclass. On the other hand having robust MockMvc tests that shoot through all three layers would not need any modifications - and we are free to perform our refactoring. I state that ease of future refactoring is main benefit of TDD.
Sir I am an QA engineer in india.i am using selenium automation tool.i don't know how to do integration testing using automation code.sir can you please share me one video for that integration testing.
Integrated tests are different from integration tests. One is an anti pattern, while the other isn't.
Great thanks!
Thanks for the comment! I'm glad it's useful :)
I think should be relation of 1 to 10 or even more for Integration Tests Vs Unit Tests. The problem I see is that some developers only use Integration tests. As a TDD practitioner my coverage is normally high and use Integration tests just to examine the code works correctly. Also perform some pair testing with QA just to explore alternative scenarios. Also a good strategy is to create a general end to end test for every acceptance criteria and apply double TDD feedback loop.
0:22 and 0:39 give me deja vue
😆