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

@enot2140

2 ай бұрын

Nothing like Behaviour Driven Specific Monitoring with some Chosen Behaviour Testing

@ThaitopYT

2 ай бұрын

I see what you guys did there. lol

"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).

@Kalasklister1337

2 ай бұрын

To me it sounds like you are just hammering home what seems to be Dave's main argument for TDD. Writing test first helps you to design your software such that most of the things you mention are no longer a problem. I get that at a certain point things can get odd and complex but overall it should help a lot if the whole team is exclusively doing TDD

@user-cu4bk2gm6q

2 ай бұрын

@@Kalasklister1337 we've been doing TDD for years and it's not a problem with TDD or BDD. It's about how the trend of what it means to write Unit Test. There is a trend that writing Unit Test at API level, which is weird. In my team, we have Integration Test and Unit Test. For Integration, we have Contract Test which test at API level and we have other integration test to test for say, a complex query against the database. Our Unit Test focus on the low levels, more specific and focus on single responsibility, just like clean code. It's independent and isolated. I support the statement, "when a test fail, I want to know why". That's what we do, and from our experience, testing at high level, most of the time, never tells you why. Testing at high level is like manually testing an API and the API get 5XX internal server error. How does the test help you to know why? You'll have to debug through the code. When you have isolated low level test, you would've prevented that problem in the first place, especially when doing TDD, every function you deliver is tested and verified to work. In ContinuousDelivery or DevOps, a team is suppose to work together delivery single work, that means, for a single User Story or feature, can have multiple developer working together commiting to the same code base and in TBD we need to make our changes really small, push frequently, collaborate frequently. This also means that you could be writing a single function that someone would use or call later, and if you only test at high level, how would know the function works? Only during integration? When I first learn about TDD, this was the phrase that convinces me, everything in the world was tested first before build, why is not software, and it starts with the smallest unit, e.g. a brick is a unit that is used to build a house, the brick is unit tested before build. You can mass produce all the bricks and after building the bridge you find that the bricks aren't strong enough? Same goes for software, in my team, every unit/function we deliver should be tested, and these units exxists based on a requirement, e.g. what determines a coupon is valid for a Product, what determines is a Product is active, etc. these units are used later in several API, and those API don't need to test then again because these smaller units has been tested and verified. We don't want to repeat the same scenario on every API; this is what happen when testing is done at high level (API) and it happen is some projects I've work with, the team is repeating the same test scenario on different API that have similar requirement... And when the requirement for say, validity for a Product change, it affect several API test but there is only one implementation that needs to change

@Kalasklister1337

2 ай бұрын

@@user-cu4bk2gm6q Oh i see. I also agree that you should push tests lower down as long as it makes sense. If you have a huge team and very high reliability requirements, i guess you can test every function. Imo tests lose a lot of their appeal if you test every function (implementation) and not just the parts that are relevant for the spec. Whenever you refactor you also have to refactor every test. Lets say we have a simple object that has one public method that is relevant in terms of spec and three private methods that are just helpers for it. I would only test the public method and leave it to devs to change the implementation as they like as long as the public one returns what it needs to.

@user-cu4bk2gm6q

2 ай бұрын

@@Kalasklister1337 yes, there needs to balance and test should be based on a requirement, so that the implementation can change but there no change to the test if there is no requirement change. For testing only public method, it's also another tricky situation because from my experience, many dev will make a method private just to avoid testing. for me, a test should not have too much responsibility or scope, then it's difficult to managed, imagine a test having over 30 scenarios, which is having dependencies. Public method A calling private method B, which have condition that will call private method C or D, and in private method C, it is calling private method E and F.... Imagine trying to test everything on A, or they only test the outcome of A... If the scenario only focus on A, and when A fails, they would need to debug through the code, that's when we have to take a step back, look and review our test... Is the test helping us finding out why it failed? Or it just tells us something fail, go and find out? For us, it took us quite a while to find the balance and what we have been practicing now is, when we review code (not Pull Review, since it's TBD, we do pair review sometimes mob review) and the way we review is look at test first, we want to know if the requirements are covered, does the test make sense? Can we understand the test? The implementation is less importance as we progress because you can always refactor and improve your code, but without a test coverage, you will have less confidence to refactor or might be wondering what was the actual requirement (e.g. legacy code where the original implementer left and there was no test, and nobody knows why it was behaving this way.) One thing we learn is also to have the mindset of others looking at the test and being able to understand easily and jump into making changes required. It really helps when we're reviewing codes in pairs or mob synchronously, we get immediate feedback from other devs but also we can observe how well our test can be understood by others, and what do we need to improve.

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.

@banatibor83

2 ай бұрын

Acceptance should change only when the requirements change. Unit test and TDD are needed for code correctness and to come up with a easily changeable design on code level. Acceptance tests needed to ensure the code does what it should do.

@fang_xianfu

2 ай бұрын

"Hope that you somehow..." is a very strange way to put it. Writing code that meets the requirements is the whole point of this job, it's not magic, it's software engineering. The first thing you do is understand the requirements, and then you write those requirements in a formal language. That's acceptance tests. If your requirements change too often, that's a failure of management.

@ffatheranderson

2 ай бұрын

@@fang_xianfu I am working as java software developer for 13 years and I can’t agree more with your statement. I have worked in so many projects where management is unable to understand that if they are unable to write expectations clearly in forms of “given when then” - then it means they do no really understand what they want. But in every single project managers were just not competent enough to understand it and were not competent enough to admit it. To me as a software developer it feels like job of management is to “convince” people around that they are competent and if somebody is pointing out that they are not really able to articulate their expectations in the inly form that is viable for software developers “given when then” - then they just become defensive and aggressive towards you and 2 or 3 months later you are taken off the project… ☺️ I experienced this 3 times.

@ffatheranderson

2 ай бұрын

Now I know which consulting company I should avoid if you are asking such questions…

@orlovskyconsultinggbr2849

2 ай бұрын

@@ffatheranderson It's ok, there exist many more consulting companies, still it won't solve your problem which you described. Why your management is incompetent ? If they really incompetent , that means they hire you too because they were incompetent? No, i think the real problem is in the way how you communicate with your managers, you cleary unable to communicate tech challenges to them, and they are not able to communicate to you the right requirements. I think it would make sense for your company to hire external consulting company, so that the business processes in your company can be improved. Typically it would consist: Assessment and Analysis, strategy development and finally finding proper collaboration tools , workflow automation and when it make sense real-time Dashboards and reporting . Simply put, change how you communicate to your management can be beneficial for all involved sides, because the blame game can be played indefinitely. Obviously it would not be done by my company which would help you, but rather by somebody else. 😃😃😃

It’s quite sad that so many people think BDD is incredibly deep and profound. It’s a pretty small and simple idea. When is Dan North going to sue Tony Hoare? kzread.info/dash/bejne/la6u0pqgfai5g7w.html 😮

@orlovskyconsultinggbr2849

2 ай бұрын

Behavior-Driven Development (BDD), as previously mentioned, serves as an acceptance test, providing an additional hurdle for developers to address. However, a common issue with BDD lies in the fact that these acceptance tests are often authored by developers rather than the product owners, requirements analysts, or business analysts. Consequently, when the actual requirements evolve or shift, there arises a need for these acceptance tests to be adaptable. It becomes crucial to ensure that the tests remain relevant and aligned with the current needs of the project. Yet, maintaining stability in requirements and ensuring that evolving requirements are adequately addressed pose significant challenges in the BDD process.

@heavymestworker

2 ай бұрын

@@orlovskyconsultinggbr2849 yes, but it’s no big deal.

@dafyddrees2287

2 ай бұрын

@@orlovskyconsultinggbr2849 yes, but it’s still pretty simple stuff. I wish it hadn’t been elevated into a religion. I was joking about Dan suing Tony Hoare. But it really is time to understand that it’s just one approach and that there are lots of other ideas - some of which could be better.