BDD's REAL Role In Software Testing

___________________________________________

🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS

___________________________________________

#softwareengineer

[dejw]

Love the evolution of acronyms in our field. Waiting for Behavior Driven Specific Monitoring. ;)

[orlovskyconsulting]

So BDD goes like this: write acceptance test, write unit tests for testing the code and hope that you some how able to implement code for passing acceptance test.
What if acceptance test constantly changing, then you get really fast frustrated.

[Gaming-yg]

"When a test fail, we want to know why".
That is why we should understand why we want to write test and verify if the test benefits us or bringa value.

Usually, in given examples, the scenarios are often simple; but in complex business application, a business requirement can be complex and thus the scenarios can be alor and complex, and then there is technical complexity like what if we're passing invalid values like invalid datatype, null, etc. The thing I notice is, nowadays people tend to focus on wroting test on high levels only, (e.g. API Level Test), and usually when this fails, it doesnt tell you exactly where went wrong and you most likely need to debug the code.
This is like manually testing the API, and something unexpecte happen and you need to debug them.
The issue can even be further complicated by writing high level test as unit test, which would require mocking of other services or the dependent databae and when you need to mock these which are nested deep inside the codes, it creates complexity and unreliable test. These should instead be integration test or contract test, which needs proper setup and keeps the test simple however, it takes much longer time to runs and when there are complex business scenarios, the test get complex and it doesnt really tell you what went wrong (e.g getting a coupon via coupon code which requires checking if the coupon is valid for the customer, the coupon is valid for the product, coupon is valid for the sales period, coupon is not fully redeemed, etc - testing these on high level with such complexity requires complex setup and difficult to trace what went wrong especially there're logics deeply nested in the codes which could have been unit test individually and in isolation).

The issue I notice is that people are just following the trend, like write test only at high level and people are applying it on Unit Test which IMHO, unit test should be fast, small, independent, isolated. When testing at high level, and the unit is calling other units (Coupon Controller calling Coupon Service caling Customer Service, calling Product Service, calling Coupon Redemptoon Service, etc), it's no longer indepedent and the test will be flaky and complex.
I think Clean Code concept of Single Responsibility applies to Unit Test as well; if we dont isolated the test, we're testing too many things for a single unit, but if we isolate the unit justblike clean code, then we only focus and test the responsibilty of the particular unit (e g. coupon valid for given product).