Hoang (Eugene) Nguyen’s Post

What is #BDD then? BDD ≠ Gherkin tests Following on from my post 'You're Not Doing BDD', a run-through of what the process really is. Defining Behaviour Driven Development. https://lnkd.in/e-ZGpPUF

𝗜𝗥𝗲𝘁𝗿𝘆𝗔𝗻𝗮𝗹𝘆𝘇𝗲𝗿: Listener of 𝗧𝗲𝘀𝘁𝗡𝗴 𝘂𝘀𝗲𝗱 𝘁𝗼 𝗿𝗲-𝗮𝘁𝘁𝗲𝗺𝗽𝘁 failed test cases for a certain number of times. it is an Interface having one 𝗿𝗲𝘁𝗿𝘆 𝗺𝗲𝘁𝗵𝗼𝗱 , so we need one concrete class to implement this Interface and as a result need to implement 𝗿𝗲𝘁𝗿𝘆 method, owing to which we can achieve 𝗥𝗲 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 of test cases on the fly. This is 𝗵𝗲𝗹𝗽𝗳𝘂𝗹 in cases where the 𝗲𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁 𝗶𝘀 𝗳𝗹𝗮𝗸𝘆 but note this is an organization's choice whether they want to execute test cases against a flaky environment. Can we use 𝗜𝗿𝗲𝘁𝗿𝘆𝗮𝗻𝗮𝗹𝘆𝘇𝗲𝗿 𝗶𝗻 𝗕𝗗𝗗 𝗖𝘂𝗰𝘂𝗺𝗯𝗲𝗿? Answer is 𝗬𝗲𝘀. If we are using 𝗕𝗗𝗗 𝗰𝘂𝗰𝘂𝗺𝗯𝗲𝗿 𝘄𝗶𝘁𝗵 𝗧𝗲𝘀𝘁𝗡𝗴. Let us dive deep in to practical demonstration https://lnkd.in/dxvUaSv6 If you want to 𝗹𝗲𝗮𝗿𝗻 𝗕𝗗𝗗 𝗖𝘂𝗰𝘂𝗺𝗯𝗲𝗿 𝗳𝗿𝗼𝗺 𝘀𝗰𝗿𝗮𝘁𝗰𝗵, 𝗰𝗵𝗲𝗰𝗸𝗼𝘂𝘁 𝘁𝗵𝗲 𝗳𝗼𝗹𝗹𝗼𝘄𝗶𝗻𝗴 𝗽𝗹𝗮𝘆𝗹𝗶𝘀𝘁: Mastering BDD from Scratch || For Absolute beginners: https://lnkd.in/dWFQbf2g Follow us on Following channels for regular updates 𝗬𝗼𝘂𝘁𝘂𝗯𝗲:https://lnkd.in/gmPT55FY 𝗪𝗵𝗮𝘁𝘀𝗔𝗽𝗽: https://lnkd.in/gVqWAwg3 𝗧𝗲𝗹𝗲𝗴𝗿𝗮𝗺: https://lnkd.in/gjyMJwdD Regards PrinceAutomationDestination

"TDD is writing the tests first" is a terrible phrase. We need to do something about that. You don't write "the tests" first. That is a plural, and often when it is expressed that way people imagine the same tests that they would have written after the code was completed. That's all wrong. You write one test, then implement enough code to pass that test, then refactor the existing code and test(s) if necessary, and then maybe commit or integrate before you get too much divergence from the main branch. You don't write "the tests" first. You write a test first. The test you write isn't a test of the code you haven't written. It is a test of what you want the code to do (that it doesn't do yet). It's a whole different mindset over writing tests to get coverage for existing code. I lack the imagination and genius to write all of the test-last tests before writing the code. I have no idea how anyone would do that. But I have ample skill and knowledge to write a test for what I want to happen before I write the code that makes it happen. Do I want to throw an exception on bad input? Cool - here's a specific bad input, and here's the expected exception. We can do this for a lot of kinds of bad inputs, but we'll take it one kind of badness at a time. Do I want it to count the words in a sentence? Sure, here's a sentence and here is the dictionary of words to counts. I can give it a lot of specific sentences to test it's counting prowess, but only one at at a time. This is, sadly, not what people imagine when they hear "In TDD you write the tests first" -- they picture something that is much harder, much less likely, and much less applicable. You'd think that in 29 years we'd have at least gotten this idea into the hive mind, but the field keeps growing (and filling with misinformation) faster than we can teach it.

There is a best tool for BDD. Use the xUnit-compatible tool for your language! But that's not the tool. The tool is your own mindset. People who are able to test behavior using xUnit-like tests, are people who have made the mental leap, who have really internalized what "behavior" really means. Also, 🥒 leads to more friction: - disconnects the SUT from the spec, meaning harder to learn about the concrete code by going through the spec - be honest: your stakeholders neither read, nor write those specs - have you ever tried to change the "BDD specs"? it's just a pain Testing behavior with xUnit tools means: - you right click on element, find usages, and you got all code relevant to your behavior - you execute your test with code coverage, and you get an even more precise understanding with a few clicks, not hours of sifting through code #tdd #bdd #softwarearchitecture #cucumber

𝗜𝗥𝗲𝘁𝗿𝘆𝗔𝗻𝗮𝗹𝘆𝘇𝗲𝗿: Listener of 𝗧𝗲𝘀𝘁𝗡𝗴 𝘂𝘀𝗲𝗱 𝘁𝗼 𝗿𝗲-𝗮𝘁𝘁𝗲𝗺𝗽𝘁 failed test cases for a certain number of times. it is an Interface having one 𝗿𝗲𝘁𝗿𝘆 𝗺𝗲𝘁𝗵𝗼𝗱 , so we need one concrete class to implement this Interface and as a result need to implement 𝗿𝗲𝘁𝗿𝘆 method, owing to which we can achieve 𝗥𝗲 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 of Failed test cases on the fly. This is 𝗵𝗲𝗹𝗽𝗳𝘂𝗹 in cases where the 𝗲𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁 𝗶𝘀 𝗳𝗹𝗮𝗸𝘆 but note this is an organization's choice whether they want to execute test cases against a flaky environment. Can we use 𝗜𝗿𝗲𝘁𝗿𝘆𝗮𝗻𝗮𝗹𝘆𝘇𝗲𝗿 𝗶𝗻 𝗕𝗗𝗗 𝗖𝘂𝗰𝘂𝗺𝗯𝗲𝗿? Answer is 𝗬𝗲𝘀. If we are using 𝗕𝗗𝗗 𝗰𝘂𝗰𝘂𝗺𝗯𝗲𝗿 𝘄𝗶𝘁𝗵 𝗧𝗲𝘀𝘁𝗡𝗴. Let us dive deep in to practical demonstration https://lnkd.in/dxvUaSv6 If you want to 𝗹𝗲𝗮𝗿𝗻 𝗕𝗗𝗗 𝗖𝘂𝗰𝘂𝗺𝗯𝗲𝗿 𝗳𝗿𝗼𝗺 𝘀𝗰𝗿𝗮𝘁𝗰𝗵, 𝗰𝗵𝗲𝗰𝗸𝗼𝘂𝘁 𝘁𝗵𝗲 𝗳𝗼𝗹𝗹𝗼𝘄𝗶𝗻𝗴 𝗽𝗹𝗮𝘆𝗹𝗶𝘀𝘁: Mastering BDD from Scratch || For Absolute beginners: https://lnkd.in/dWFQbf2g Follow us on Following channels for regular updates 𝗬𝗼𝘂𝘁𝘂𝗯𝗲:https://lnkd.in/gmPT55FY 𝗪𝗵𝗮𝘁𝘀𝗔𝗽𝗽: https://lnkd.in/gVqWAwg3 𝗧𝗲𝗹𝗲𝗴𝗿𝗮𝗺: https://lnkd.in/gjyMJwdD Regards PrinceAutomationDestination

One of the other misconceptions to be wary of: Test Driven Development is not about how a tester will test the code, let alone make the tester (QA) ready before dev ends. Test Driven development is a form of "development" - where the developer thinks in terms of testing first before thinking about the implementation. TDD is for the devs not QAs! #TDD #TestDrivenDecelopment #GoodCoding #SoftwareEngineering

#LLMs and #BDD - The good, the bad, and the hallucinations I have been experimenting with Mistral, and now with Llama3, and they show promise, but are clearly not there yet. Llama3 is clearly better than Mistral 7B, but still makes absolute beginner mistakes when prompted with "Please complete this scenario for searching a library catalog: 'Scenario: The catalog can be searched by the author's name'". I counted five mistakes in a four-line scenario. Both Mistral and Llama3 also hallucinate badly - I asked Mistral to recommend resources that would help me train an AI such as Mistral to be an expert in a specialized domain such as BDD. Mistral gave me a list of nine articles or papers - title, author, and URL - but none of them actually exist. Mistral said that Gojko Adzic wrote one of the papers; I asked Gojko and he said "I've never done a presentation on that". Llama3 gave me a list of books, some are real and some aren't. "Deep Learning" by Ian Goodfellow, Yoshua Bengio, and Aaron Courville is a great book, but "The Cucumber Book: Behaviour-Driven Development for Java" by Aslak Hellesøy, Richard Lawrence, and Luca Mezzalana doesn't exist. This appears to be a mashup of "The Cucumber for Java Book", written by my friends Seb Rose, Matt Wynne, and Aslak Hellesøy, and "Behavior-Driven Development with Cucumber", written by my friend Richard Lawrence. My favorite hallucination was when I asked them to "Please summarize the article "Never Google 'BDD Tutorial'"". Mistral said that Gojko wrote it; Llama said "A classic! ...by Dan North..." I wrote it. 😂 https://lnkd.in/e55zEM-u I suppose now I have will have write a new blog post "Never ask an LLM about #Gherkin"! 😁

I wanted to share an interesting short video from Petros Plakogiannis that clarifies what BDD is and what it isn't. BDD goes beyond using tools like Cucumber or Specflow and writing feature files in Gherkin syntax. It emphasizes communication between the business and technical team, fostering the use of a common language. Watch the video here: https://lnkd.in/dZFYZxiH

Cucumber is a popular tool that supports Behavior Driven Development (BDD) framework. Here we define the application behavior using Gherkin language, a simple English text that is understandable by both technical and non-technical stakeholders. In the feature file, the Gherkin syntax uses Given, When and Then keywords to define the pre-conditions, actions and expected outcomes respectively. Read more on this amazing blog by Pratibha Venkatesan https://lnkd.in/gXRjxgNR

Having enough skill and knowledge to write one test does not accumulate into having enough skill and knowledge to write the program. That's a very appealing fallacy that accounts for the popularity of the method. You mean I can write a non-trivial program without learning how to do a data structure decomposition or a case based analysis. No you can't. But TDD makes you think you can. Writing the tests (plural) first is actually better because your mind plays tricks on what your sense of a correct result is once you start seeing some tests results. I believe the term for this is confirmation bias. It's not a TDD/Test Last dichotomy. You write as many tests as you can think of up front - if for no other reason but to validate that you know what the heck you are supposed to be doing before you start writing any code. Lastly a very simple example of how you can write the wrong code and still get the test to pass. The requirement involves flipping a shape vertically, you code it by flipping the shape horizontally if you test that code with a circle, rectangle or square the test will pass but the code is wrong.