Timeline for Unit Testing business logic layer that depends on data access layer [duplicate]
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 25, 2019 at 11:38 | history | closed | gnat Doc Brown Greg Burghardt BobDalgleish jwenting | Duplicate of Do I need unit test if I already have integration test?, How to test database dependent functionalities? | |
| Nov 21, 2019 at 15:30 | comment | added | Filip Milovanović | If there's logic in DAL that needs testing, a different set of tests exercising the logic in your DAL should fail, and possibly some integration tests. And if you change the interfaces, then, depending on how the thing is set up, either the tests (and the code) won't compile, or they will run and crash, or some integration test will fail. If none of that happens, then you should write better, more specific tests. 2/2 | |
| Nov 21, 2019 at 15:30 | comment | added | Filip Milovanović | The whole point of having layers is that changes behind the interfaces of one layer will not cause the code in another layer to fail. So those tests shouldn't fail; also mocks don't represent the internal logic in DAL, they represent the data returned by the DAL in a format specified by the interface between those two layers (or externally visible behavior). So they shouldn't reflect internal behavioral changes in DAL, only the changes that affect the layer boundary, and you shouldn't have to adjust the BLL (otherwise, you have coupling). 1/2 | |
| Nov 21, 2019 at 14:19 | comment | added | Sharon Ben Asher | @FilipMilovanović, maybe I didn't explain clear enough: if the data access layer is mocked, then any changes to it are not reflected in the unit test of the business logic layer. if the logic inside the data access layer is changed, I expect the unit test of the business logic layer to fail, reminding me to adjust the business logic layer to the modified data access layer. this will not happen in a mocked data access layer. so basically I have to remember to change the unit test of the business logic layer in case of changes to the data access layer. | |
| Nov 21, 2019 at 14:13 | comment | added | Filip Milovanović | "returned mocked value maybe obsolete" - your test should have full control over the returned value, otherwise, it's unpredictable. You are not testing the database, you are testing the code that works with those objects; your tests should be very specific. If the database returns something different, that requires different processing logic, then a different test should cover that. And if the core logic itself changes, then you simply have to rewrite the test(s) anyway. | |
| Nov 21, 2019 at 13:10 | answer | added | Halil İbrahim Özdoğan | timeline score: 3 | |
| Nov 21, 2019 at 12:59 | answer | added | Rumen Georgiev | timeline score: 3 | |
| Nov 21, 2019 at 12:45 | review | Close votes | |||
| Nov 25, 2019 at 11:38 | |||||
| Nov 21, 2019 at 12:38 | comment | added | Doc Brown | Possible duplicate of Do I need unit test if I already have integration test? Note your option 2 is "unit testing", your option 1 falls into the category "integration testing". | |
| Nov 21, 2019 at 12:25 | review | First posts | |||
| Nov 21, 2019 at 14:09 | |||||
| Nov 21, 2019 at 12:21 | history | asked | Sharon Ben Asher | CC BY-SA 4.0 |