Amongst other things Emily and I talk about the importance of Refactoring in this episode. If you'd like to learn more, I have a free "How To" guide to refactoring which you can find here: continuous-delivery.co.uk/downloads/How%20To%20-%20Refactor%20Legacy%20Code%2013-07-2023.pdf
@EmilyBache-tech-coach Жыл бұрын
Thanks for having me on the show, Dave. Listening to it now I realize we did get into quite a detailed conversation about Approval testing amongst other things. It's fun to talk to someone who is as knowledgeable as you are. Although, I don't think we completely agree on when to use this technique ;-) We do agree on a load of other things though - Margaret Hamilton is a hero of mine too! I hope people like listening to us chat about all this. It feels like it really was an *engineering room* discussion.
@ContinuousDelivery Жыл бұрын
Emily, it was my pleasure, thank you for taking part. I think that I am a natural heretic, I nearly always disagree about something, but I take it as a sign of my curiosity, more than dogmatism. I like to express my ideas as clearly as I can, even if I disagree with someone, so that they can correct me where I am wrong. I think we agree on a lot more stuff than we disagree on, it is always interesting to find the bits where our interpretations differ though, as long as we can agree to disagree agreeably 😎
@jimiscott Жыл бұрын
Emily is a great guest. We use Approval tests extensively - primarily to test the output (which are files of different types - JSON, Xml, CSV, etc) of large, complex, configurable object interactions - the unit tests are there to test the individual aspects, but the approval tests ensure the system is working together as desired.
@ccomeau79 Жыл бұрын
From her book, first thing I looked for after picking it up after watching this video: "Samman" is Swedish for "Together". Same meaning as Ensemble coming from French. That's a helpful bit of info to help the name catch on - gives it roots and the association makes it memorable. Much better than saying it was a random arbitrary name you made up! I'd put that as one of the first things we see on your site - really helps sets the context and clears out a lingering "what does samman mean?" question.
@EmilyBache-tech-coach Жыл бұрын
That's a good idea! I do usually say where the name comes from. Thanks for taking the trouble to look up what it means and writing it here. Hope you enjoy my book!
@darshandev1754 Жыл бұрын
It means respect in hindi and a few other indian languages, I wonder if theres a common language between them
@ccomeau79 Жыл бұрын
@@EmilyBache-tech-coach I just skimmed through so far, but it looks like you might not have come across perceptual exposure learning yet - check out "Badass: Making Users Awesome" as a useful starting point. I think propagation of tacit knowledge is a great argument in support of ensemble work. It's the same concept as how children of proficient parents grow up seeing many diverse examples of what to do, when, and how, in many situations, and appear to have natural talent as a result. There's value in simple seeing so many good examples, since our brains are great at picking up on how things relate, in ways that can't always be expressed in concrete terms. Kind of like "deep learning" for humans.
@ccomeau79 Жыл бұрын
@@darshandev1754That works out nicely then, it's in line with another theme she talks about. Much better than hearing it meant something unpleasant or offensive
@darshandev1754 Жыл бұрын
@@ccomeau79 😆
@schmoab7 ай бұрын
As a QA engineer and not primarily a developer, this is how I write many automated tests. It separates test from implementation.
@iPwnPancakes Жыл бұрын
What a good episode! One thing I did pick up about Emily's approach to Approval testing, is that it seems like it allows her to define a "fuzzy" definition of what the expected outcome could be. You could start off with a fuzzy definition, and once you've implemented it you'll see whether or not you're closer or farther away from a solution. I do also see though that this works in contrast to my understanding of Acceptance testing, where you define a clear and computable idea of what the outcome should be.
@adamlawrence3651 Жыл бұрын
This all rings so true to me. 9 months in to a new job, where the code base has done integration testing at API level, and e2e which gives us some coverage, the backend code is not too bad, although not all unit testable. front end code has almost no Test coverage, I have been trying to introduce cypress component testing, as well as unit testing where it makes sense. feels like I am pulling out teeth at times, so hard when everything we develop is needed yesterday.
@LoftyCuber Жыл бұрын
I've been a professional developer for 5 or 6 years now, but have always had the problem you mention Bob Martin talks about of not having anyone more senior from me to learn from. I'd love to join one of these remote open ensemble groups or open mob programming groups to be able to be exposed to how more people think about writing software and learn from each other. Is there a website or way you'd recommend to be able to join one of these groups? My google skills couldn't find anything current. Thank you!
@gc2009able Жыл бұрын
I would be interested in something like this, too!
@banatibor83 Жыл бұрын
As I see acceptance test vs. approval test, they are almost the same thing. When you refactor a legacy code and you create an "insurance" it is an approval test. It ensures you do not change the behavior. When you develop a new feature it is an acceptance test. I am pretty sure you can write an approval test in any BDD framework.
@LoftyCuber Жыл бұрын
The main application I work on has the main purpose of generating an output file. We have unit tests for most of that back end logic, acceptance tests with SpecFlow for the GUI, but have always been at a loss for testing if the output file is correct. I could see something like Approval testing being what we are missing to test that last part of our application.
@EmilyBache-tech-coach Жыл бұрын
My follow-up video explaining what Dave Farley still doesn't get, even after this engineering room conversation: kzbin.info/www/bejne/oIDYoniVpJ6lo8k
@DiogoMudo Жыл бұрын
So, Dave keeps repeating to us to be incremental, to have a "step-by-step" approach. He touches the airpod button, and it starts saying "NEW KID ON THE BLOCK".
@Tony-dp1rl Жыл бұрын
I love how parts of this interview hint at contradicting the TDD approach, and increasing scope of testing to larger features in the code. She must work in the real world. :)
@darshandev1754 Жыл бұрын
😂
@qj0n Жыл бұрын
I don't agree approval tests are self-referential. They are only if you blindly approve the results. Once you review the results and make conscious decision about approving them, it is a partially manual test. You also get a fully automated test as well as an effect as you can make next runs without manual looking into results I don't have any commercial experience with those tests, but I believe they are a good approach wherever manual testing is tempting - that includes both gui and legacy systems without tests
@ContinuousDelivery Жыл бұрын
Interesting, that seems to me like a statement of fact. For Approval tests we run the code and save the result that we got back from the code and then in subsequent runs we compare the results with the original result. That is we refer to the original result which was generated by the code itself. How is this NOT self referential? Sure, you can mediate the self-reference by looking to see if it seems ok to you, but that doesn't stop it being self-referential, that just changes it to be self-referential-plus-sanity-check. This is not inherently bad, but it does place some limits on its value. The big problem with self-referential tests like these is that there is nothing, other than the sanity check, that says that the results that were generated make sense, or represent what you want, and certainly for many types of problem, the result that you get back from these bigger, chunkier bits of software is complex enough to make it VERY easy for the sanity check to be poor, cursory or to miss things. Humans are particularly bad at this kind of review. This is VERY different to creating a specification for what you want, before you create it, and then verifying that what you want is fulfilled by what you created. Particularly, if when you create the spec, you don't do it in a detailed "what is the precise output" form, which is what an Approval test validates. I am a big fan of Approval testing, but I don't think that they are a better replacement for BDD style Acceptance Testing. They may be easier to write, but I still think that comes at the cost of being a weaker, more coupled to the solution, assertion.
@BryonLape Жыл бұрын
Object Oriented Design was the biggest, single mistake the industry made in the 90's. I've been returning to functional programming over the last few years. Wish I could purge OO out of my head.