I'll quote one of my co-workers. "We can't afford to spend two weeks doing things properly, but can always spend two months fixing broken s**t". In many way, my feel is that tests become "expensive" because you never bothered to put in the work to make your stuff testable in the first place. Sure, DI/IoC an all jazz, but... that's mostly "scafolding", it doesn't fix the fundamental problem, which is mentality. If you don't strive to make things as much self contained as you can, you've already lost. p.s. I'd happily take even just testing "happy paths", seriously... the amount of times I've seen even that failing on production updates is WAY too high. Its not that i don't care about edge cases/conditions, but if not even the "happy path" is working properly, don't bother going further. As i usually say, "automated tests aren't there (primarily) to weed out weird stuff. They're there to make sure things that SHOULD work STILL WORK".

@megabyte01

3 ай бұрын

I had a mentor put it in a pithy way: you never have time to do it right, but you always have time to do it twice

This is a huge favor to the entire QA community :) Thank you!

Other devs breaking stuff I've written is bad for productivity. When I write tests for it they know what they've broken, fix it, and I never have to hear about it.

@gronki1

3 ай бұрын

What if your stuff needs change for project in order to move forward. Have to spend twice as long to rewrite any tests. Good for big mature project where breaking thing that already works would cost you a lot of time, not so much for rapid and quickly evolving project

@orderandchaos_at_work

3 ай бұрын

@@gronki1 If it's a big change, delete the affected tests and write tests for the new functionality.

I write my tests in parallel with my code. Not before or after, they are in the same commit. I find myself using the tests instead of a debugger because the debugger executes at the application level and the test is already built to execute the individual component (I can always run the debugger on the test). Another benefit is that the tests prove that the MR/PR is functioning within the acceptance criteria. I love the idea of TDD, but I build products from scratch using new frameworks which require learning from new paradigms to new languages.

A lot of people miss the real benefit of tests. If you think a test is just there to check if a feature works, then tests couldn't possibly increase productivity. But if you see testing as a means to get fast feedback to ensure that you're building the right things, then good tests can mean the difference between finishing in a few hours and finishing in a few days.

@sylvereleipertz955

3 ай бұрын

It tests that a piece of code is working as intended and that it stays that way in the future when others devs will join the project. It's a safety net. "The fast feedback to build the right thing" as more to do with TDD than testing itself

@georgehelyar

3 ай бұрын

You get fast feedback from users to ensure you're building the right thing. That's what agile is.

@TheRyulord

3 ай бұрын

Tests can't tell you if you're building the right thing.They can only tell you if you're building the thing right*. *They can't even really do that. They can only tell you that it's correct. They can't tell you if it's performant, maintainable, etc.

@berkes

3 ай бұрын

Even if tests only check that something works as intended, it can be a time saver. I've worked on systems where I ran through the login screen literally hundreds of times per day. My IT-brain immediately thinks: "it would be faster to write a script that does this logging in for me". Obviously tests are much more than automation of repetitive and time consuming manual work. But even as only that, extreme time savers.

@fang_xianfu

3 ай бұрын

​@@sylvereleipertz955 the "other dev" can easily be yourself 6 months from now when you come back to something you haven't touched for a long time and don't remember how it works, as well

I know what I'm about to say goes against what most industry experts teach, but I've always believed that integration tests are more valuable and more important than Unit tests. Integration tests will test general behaviours of the system. They both validate that everything is working and working together, and since they are higher level they are closer to testing the behaviour of the system. They are more expressive of what the system (or that corner of it) is supposed to do and that it keeps doing it. While being more likely immune to being impacted by refactoring. But yes, they are slower to run, and no they are not the place to be verifying all of the permutations of every minute case, and if you're chasing coverage numbers than these get messy fast. Unit tests on the other hand are only verifying the smallest parts of the system. Yes they do run faster, and you can cover more cases of that minute part of the system. But they're more prone to requiring change in a refactor as you change your units, in which case you lose your confidence that everything is still working as intended because your tests have changed and been rearranged as well to match the new refactoring. And then they don't tell you what the system does. Unit tests show you the trees, integration tests show you the forest. I'm not saying unit tests aren't valuable at all, I'm just saying that I think integration tests should be valued higher than they generally are. To the point that if I was only forced to write one kind of test I would choose integration tests. But ideally we should be writing both.

@barneylaurance1865

3 ай бұрын

That might depend what you mean by "unit test". If you write so-called "Sociable unit tests" then you're not only verifying the smallest parts of the system. You're testing slightly bigger parts.

@sealoftime

3 ай бұрын

@@barneylaurance1865 sociable unit tests still suffer from becoming mocked with incorrect dependencies. That's why I vouch for using mocks, that are contract-tested against the real implementation, and are made universal i.e. in-memory storage instead of just On("GetUser").Return(FakeUser)

@pauldanielmooney

3 ай бұрын

@@barneylaurance1865 “sociable unit tests” : thank you I’ve been looking for this term for a while now. This sounds like the thing which I’ve heard many refer to as “integration tests” but seemed to be a special case of integration test that doesn’t require any outside processes such as a database.

@barneylaurance1865

3 ай бұрын

@@pauldanielmooneyYou're welcome. I noticed a mistake in my reply, I meant to say "not only verifying". Now edited.

@ApprendreSansNecessite

3 ай бұрын

I also thank you for the term "sociable unit test". I find it hard to communicate about testing for lack of ways to define the unit under test. I try to avoid mocks when possible and I don't want to test the internals of my apps, so I identify stable abstractions, unlikely to change on small refactors, and I test these as units. I also don't mind tedting viewModels rather than UI components themselves, unless they have state, which I try to avoid with a state machine or an event store. I have just a few integration and e2e test to check that things are connected properly, but these tests need not be exhaustive. Testing the behaviour of software is a distinct concern for me, it's a business concern and it has its own suite of tests, which could even be run with something like Cucumber

Thank you, thank you, thank you! "I don't have time for testing" == "We need to improve _how_ we spend time testing" Great video!

Testing how things should work. That is easy Testing how things should not work. Thats a different beast. For every 1 thing you do right, there are 10 ways it could go wrong and you need to account for each one. I am writting a JS library and half the library is error handling (1.5k). I expect it too get much bigger

This is the video that was missing about software testing! I always though about these questions but never heard anyone speak about it so clearly.

Faster to TDD than to debug in production. Also much faster to iterate with tests than whole programs.

I write a lot of tests for someone who doesn't like tests. I do it because it's easier than to manually debug all the time

@Rope257

3 ай бұрын

Talk to your team, you writing tests for someone else shouldn't be happening.

@RicciardoJohnson

3 ай бұрын

@@Rope257 lol

@Rope257

3 ай бұрын

@@RicciardoJohnson Thanks for this supremely useful reply.

@vetrivendhan6122

3 ай бұрын

You are doing something great. I hope your manager is appreciating you. 😊

Fantastic video, thank you 🎉

Thank you, Trisha! This added some important thoughts about testing which are also encouraging 🌺

Always love the topic. One feedback regarding your summary in the end: The text is blue on a blue background. Difficult to read even for people with healthy eyes like me. But all in all great talk. Love the idea of writing tests to keep track of what the code should be doing. Writing production code on the other side is what your code is actually doing. Will use that from now on ❤

I would love to see a video about when to delete unit tests that are no longer needed because we have more useful unit tests that test more code.

What a great video, really fits the channel. I also really like your hair! (purple and white are my favorite colors)

Just supporting with this commet. Great job ! Thanks Trisha!

I love unit testing backend. Testing frontend... there are 1,000 tools, none of them are perfect, and there's never a great approach that doesn't feel like a huge waste of time. Do manual tests while working in Storybook? Mock fetch and check that clicking the button clicked the button? Snapshots? Throw your hands up and only do E2E?

Finally a realistic approach to testing rather than the dogmatic message on testing from Dave. Great video/explanation Trish.

@tongobong1

3 ай бұрын

Yes Dave is lost in the theory that is far from reality.

Spot on! I would like to thank you for making such videos: they help us to communicate best practices to colleagues and management. Thank you! 🙏

Great video. Writing test saved me a lot of time in development. As I also use them to get values to units I get get them almost for free. Long running tests may be an indicator for a performance issue in the tested code. That would be an opportunity to improve the product before the user complains. The decreased output due to tests defintely outweighs the time and effort spent on hotfix releases.

Great video Trisha!

One of the biggest obstacles to TDD is that language support and frameworks for testing often are written in ways that require different knowledge and skill sets than writing application code. Some of this is on how we train developers (how many "hello, world" tutorials start with writing a test?), but a lot of it is because testing frameworks are designed and implemented by people who are testing-focused rather than application-focused; their objective is to come up with feature-complete test frameworks, rather than produce a working application.

Great video, consice with good explanation, I looking forward to seeing more like this, great job 👍

If you don't test now, you will have to debug (a lot) later. It is as simple as that.

@cthoadmin7458

3 ай бұрын

And expect angry customers when you release low quality stuff. My experience is customers will forgive you if it's late, but tend to be less forgiving if it's broken.

I think TDD is wrongly called test-driven development, it should be called test-driven design. The set of qualities your code requires to be testable is the same set of qualities it requires to be considered "good software design". Asking "how can I test this code" is fundamentally the same question as "how can I improve this software design". Test-first thinking (i.e. start with the end in mind) is an incredibly powerful idea. Engineers often complain about not getting software specs, well, often the people who are asking us to do things are not qualified to write a spec at that level - nor should they be! That's our job! Using test-first thinking, you can start by writing a manual test-plan which eventually produces a software specification - they are one and the same, i.e. a list of things the system should and shouldn't do. To be frank, any engineer worth their pay check is doing TDD one way or another - they start by thinking "how will I know this is working" and "how will I know this is STILL working 3 years from now". If you can learn to think this way you'll instantly stand above many of your peers as an engineer, guaranteed.

@lllevokelll

3 ай бұрын

Yes, but if that is true (and I think it is), can you not write your code AS IF you were going to test it, but then not actually test it, getting 80% of the benefits, with none of the painful time/effort expense to write and maintain tests... The dirty secret of TDD is that it's an inefficient use of time, for 20% of the value. If you mindset of writing short, low or no side effects, test friendly code, you are already 80% good, without the tests.

@MrMate12345

3 ай бұрын

​​@@lllevokelllif your code is testable, writing the tests is a low hanging fruit, so why not? Btw how do you test your code without tests? Do you have some manual testing process which is executed by manual testers after every pull request? Or do you test only the possibly affected features manually yourself?

@NicodemusT

3 ай бұрын

lol you all work at IBM or something. There are plenty of scenarios where testing is a waste of time, and they can't all be waved away as laziness or cheekiness. There are restraints that exist outside of the one-size-fits-all ecosystem that so many of you work in. None of you have ever worked at an agency - responsible for 30% of all web development in our industry, and your lack of understanding of the traits of an agency setting can't all be answered by just suggesting anyone not in a privledged position such as yourself, are just not trying hard enough. You think all of these smart programmers would be able to see outside of their own perspective. And that 30%? Some of the most visited websites in the world. But don't let that stop you from preaching.

@nijolas.wilson

3 ай бұрын

​@@NicodemusT of course you can very intentionally skip writing unit tests, if you wish. Happens all the time. Skipping testing altogether is also possible, I guess, but how do agencies know they've completed the work they've been engaged to deliver? Do they not check it at all? I can't accept that anyone capable of delivering something someone else is paying for hadn't tested it at all in some way or other. Regardless of the nature of the work, the highest impact developers and engineers are starting with the end in mind. In an agency they might write a test plan upfront based on the spec / requirements, and it'll save them and their teams a tonne of time over the course of any project, especially when it comes time to crunch. Whether or not you dogmatically write unit tests, or any other specific tool, is beside my point.

@NicodemusT

3 ай бұрын

@@nijolas.wilson when you said "in an agency they might write a test plan", I knew right away you have no idea the audience. You can preach that agencies should have to write tests, but they aren't going to do it. That's just a fact that you can't wash away. We do not have the time with a project that you do. Things come in and they leave. Writing tests just fills a warm place in your heart - and does nothing for anyone else. "I can't believe someone hasn't tested something in some way" - you act like nothing has ever been done without testing - what about 1994-2010? Are we seriously pretending these years of development didn't exist? Do you think amazon 1.0 was running unit tests? There's a whole world of software development where no one is running tests and the world continues to spin. Or that every single WordPress plugin - run by millions of people in the world - do not have any unit tests. None. Not one. Not some. Zero. Save time? Any time I've ever seen a programmer running tests, he was at someone else's desk chatting while his tests are running. I agree testing can save you time, but in the same way that running can burn calories - it only works if you're not eating a slice of cake at the same time. It's actually obnoxious that you're all standing on shoulders of decades of software not built with TDD without even realizing it.

Great advice prior to having a dedicated tester perform deep and thorough testing on the product. So much can go wrong still with automated test suites.

@maxlutz3674

3 ай бұрын

Even you have a dedicated tester automated tests are valuable. They cover basics and can be amended based on the findings of the tester. Catching errors as soon as possible makes better use of the tester´s time.

A college of mine told me that he doesn't have the time to write any tests, when I asked him why the printer server they provided us can't print and why we wasted 30-40 engineering hours in a factory site far away of our office with my team. Ah... fun times.

I'd love more content on testing, also it would be great to add references on the topic. Anyway, good video !

@jprince1993

3 ай бұрын

I agree here! CI/CD lives and dies on how testing is implemented.

Writing tests is EASY once you STOP COMPLICATING about writing tests. Just write some simple straightforward tests and you are good to go and forget about writing tests for every edge condition that can occur.

Thank you for this! A nice and concise thing to show to employers and other stakeholders. Like so many have already done on this channel, i would like to emphasize the importance of testing SPECIFICATION and not IMPLEMENTATION. Our tests are there to protect our specs, not to validate that our intermediate step of calculating a+b indeed is a+b. When we test on a specification level (and following all the guidelines in the clip) we can sometimes radically change the underlying implementation while keeping the test mostly the same. This is IMO the deciding factor that makes sure that our tests actually increase our productivity every time instead of sometimes slowing us down.

@apptec7477

3 ай бұрын

any article/book you recommend on regard of this?

@gimballock2084

3 ай бұрын

I went into the comments just to write this. This is currently an issue at my job and something I aim to bring up and get under control. In the beginning, I hated tests because they kept breaking for silly reasons and I couldn't articulate what the problem was. But then I figured it out, it's when we have tests that test implementation and not specification. A problem I'm still trying to understand better, is mocking. Every single mocking you have to do to make your test work, is in my mind an implementation detail that I would prefer not to be necessary. One can't avoid this entirely, but perhaps it just comes down to making sure your classes are better separated, responsibility-wise. Then you will have fewer dependencies in a class and you can get away with less mocking, i.e. fewer implementation details in tests and more robust tests. Besides, having a lot of mocking setup in a test is confusing as all hell, and you want your tests to be readable. I would love people's opinion on this.

@Kalasklister1337

3 ай бұрын

​@@gimballock2084 If you use TDD you can usually avoid mocks because you write the test first and make sure that your signatures etc are such that you never have to mock. Writing test after writing the code usually leads to messy testing that may slow you down quite a bit, making a lot of people think that testing is very expensive when it does not have to be when done correctly (write tests before code and test specification instead of implementation) The more you practice using TDD (even if you don't like it), the more you will automatically write testable code from the get-go without thinking about it. It is something you learn through experience and once you have that experience you CAN (in e.g. solo projects) drop the tests for speedier writing since your code is high quality anyways. I would still not recommend leaving out tests because as soon as someone else needs to make changes or you have had a longer break you may use more time instead of less when you encounter bugs due to breaking existing functionality. Im also happy to hear any additional comments on this topic.

Thanks Trisha. I'm glad I'm not the only one that has trouble remembering the code I wrote a week ago :)

This is such a complex topic. - once the production code is shipped, yeah it is usually too late to write tests, from a project management perspective because priorities are shifting - it is CRUCIAL TO HAVE CONTINUOUS INTEGRATION with CI/CD RUNNING YOUR TESTS CONTINUALLY and litterally blocking you from going any further - it is hard when you begin but IT GETS EASIER THE MORE YOU WRITE TESTS, so you have to take it a step at time and start small - writing tests is litterally writing code the same way you write production business logic code but you "trigger" the later with the former. You're a dev, you should code all the time, so why not code your tests ? - tests are giving you the opportunity to REFACTOR CODE WITH CONFIDENCE by minimizing regressions. This becomes highly valuable over time because you can get your code better and better - when it is time to update or upgrade your framework or even porting your codebase to a different stack or language, having tests is invaluable even if you only have a handfull they become so appreciated

I _just_ got jobn't because "nobody has time or money to do things well", this includes any automated testing...

The same way you don't rate the value of a screw, a wire, a brick, a microcontroller or car for its testability, you shouldn't rate the value of a piece of software for it's testability. Software's real value is based on its reliability, accuracy and the value it produces for those using it. Period. So focus on producing reliable, accurate, valuable software and use testing as an instrument to achieve that. Not as a goal itself. And don't forget: how much money you spend producing software is also an important factor, so assuming testing is expensive, use testing in a balanced way and not everywhere and anytime.

In my experience, most people who criticize writing tests haven't written a single unit test in their life.

@khiariyoussef3226

3 ай бұрын

they probably did but not testing what should be tested and or didn't even write a testable code yet. they quickly feel disappointed, learning how to test requires a lot of patience and consistency.

@tongobong1

3 ай бұрын

But there are many terrible unit tests in the world. All the London style tests should be deleted because they are worse than having no tests.

@rfphill

3 ай бұрын

@@tongobong1 London style tests?

@tongobong1

3 ай бұрын

@@rfphill yes those tests that mock everything outside the class under tests are the London style unit tests.

@rfphill

3 ай бұрын

@@tongobong1 thanks!

one thing people often skipped is that writing testing is only possible ifdevelopers are capable of writing testable code

@cthoadmin7458

3 ай бұрын

That's why as a tester, I insist on testability right from the start. Are the requirements in user stories testable? Is the design testable? Is the implementation testable? Will there be suitable emulators or mocks, if not perhaps these things need to be rethought...

That was FAB! Bit devil's advocacy... nice. Push the tests down the pyramid, tests are documentation... ... and some more good things... gonna have to watch again. Can we have some more Trisha please?

I usually only write tests for complex problems and I always break the testing (of the same function) in several units and attempt to remove dependencies. My tactic is write simple objects (usually just a little more than strings/ints/doubles/etc or arrays of), that are test only, to hold the intermediate inputs and expected return values. This way I can manually modify data to simulate errors instead of depending on errors actually happening. These can also be used later to test the other side of the communication/API/function call. As an example, in a program that connects to a database to query for some data, I write an object (or more) to emulate the database, receive the query and reply. This way I can evaluate (in one or more unit test) if the query is well formed/valid, and can reply with spoof data to evaluate (in one or more unit test) how it handles correct data and how it handles errors (one error type per unit test). The same objects can later be used to simulate the program when testing the database. Obviously, the test objects might need tests of their own, if they are complex. But usually, if they are complex, something is wrong and an evaluation of how we are approaching the problem needs to happen.

I mostly think about tests as just validating the correctness of new code as well as usage documentation. Tests will usually pay for themselves by reducing integration later in the development cycle

@ContinuousDelivery

3 ай бұрын

Sorry I think that is an overly simplistic view of testing, common, but not really the point of the kind of testing that we usually talk about on this channel. Test DRIVEN Development is not about testing the code after it is written it is about encouraging us to design better systems, by preferring systems that are more testable. Testable systems are more modular, Cohesive and have a better Separation of Concerns, are better abstracted and more loosely coupled. All of these things are markers of higher quality in code. So TDD encourages/forces us to write higher quality code!

I try to test while I develop things. But this makes me think about how to sensibly measure productivity. sure, I can do things quick and dirty and someone else or future me has additional work because of this. There is also the thinking part and I regularly need to check a book, documentation or existing code for some details/ ideas. Luckily I'm not in a position that work feels like working on an assembly line and I have the time that is required. Luckily I haven't had emergencies like corrupted databases and stuff caused by my software. I had to often clean up behind others instead.

@ContinuousDelivery

3 ай бұрын

The best measures for productivity are "Stability & Throughput" as defined by the DORA group. They measure the quality of our work and the efficiency with which we can do work of that quality. You have to take both together, they don't "trade-off", you don't get to go faster by doing lower quality work. These are best described in the Accelerate book.

Testing is by far the longest pole in the continuous delivery tent and the biggest thing that software leaders struggle with. Software students never learn how to test software until they work in industry, and unfortunately they will likely pick up bad habits early in their career. Some of these young professionals become software leaders and carry these bad testing practices forward with them. I could talk for hours about the poor software testing practices I’ve encountered. For example, I’m convinced that a majority of software organizations don’t understand how to do basic unit testing. I’d say that only 10% of the companies I’ve worked with performed actual unit tests in their software delivery pipelines.

It's extraordinary the value of testing should even be open to doubt in the software engineering community... I had no idea people even thought that way. I'd like to see untested code in production, particularly in the financial services industry, that'd be interesting, assuming someone was mad enough to release it.

Very good video Trisha. This should be mandatory to learn on every University that teaches computer science.

I hear some of these advices eerily similar to ADHD coping strategies: "you cant trust your memory", "ride the wave as much as you can, write things down in the heat of it", "ADHD people struggle with set shifting, avoid context switches and proof yourself against it" and so on. In the future maybe behavioral therapists will give company management lectures.

Nice video. I don't know how a developer can be confident to say to a customer that their code works without running a test suite on it.

thanks - now all should see this and "believe" or better understand - would make our live easier :-).Butm my feeling/ experience is you can't understand you need to experience this. What i am missing though is another thing that makes test faster/ helping you to push it down the pyramid: Answer / think about the question "What NOT to test?" and get those things out of your tests.

Another thought that came to mind, lets hope you dont enter an infinite loop causing: - the program to freeze, not generating revenue - making endless calls to an paid API Surely that wont affect your "job" productivity.

I don't always test my code, but when I do, I do it in PROD.

@ContinuousDelivery

3 ай бұрын

I assume then that you work on things where it doesn't really matter if they work or not.

I think it's mostly the way people write tests. If you have to hammer out 25 tests, with test data for each of them, it's a hassle, it's grunt work. I've been trying to get my company to move to property-based testing so that test data is generated instead of written. This removes the grunt work, but keeps the thinking. What pattern should the test-data have? What should happen to it? Etc.

@cheaterman49

3 ай бұрын

The problem I'm struggling with is that CRUD testing for a bazillion entities gets very repetitive too. I was hoping this video would say something about handling repetitive tests like that.

I feel like there could and should be more systems to only re-run those tests that either have been edited or cover code that has been edited since the last test run. Nearly always those are the only ones that should be be giving a different result to to what happened last time we ran the tests. I know there's a system for that in Java, but afaik it isn't widely used. I don't think there's a system to do it in PHP. If it could work nicely, and probably with a long-lived process to run the tests, I'd think it could take us from running a test suite in seconds, to updating test results in tens of milliseconds as we type code. We'd watch for the results just like we watch for changes in syntax highlighting to know if we've made mistakes.

@jasondbaker

3 ай бұрын

You could architect your software platform using micro services or another similar service pattern and tightly constrain the blast radius of your changes. That would decrease the amount of testing you would need to perform. Unfortunately many companies build software platforms which do not consist of loosely coupled components so a small change in one component may lead to undesirable behaviors in others. They have to re-run regression tests across the whole platform after every little change.

I prefer writing tests because I value my weekends and after hours time. Writing tests forces me to think about what-if scenarios. Its also a way to explain how the code works. Most of my my bugs are associated with incorrect assumptions not bad logic. And when possible I test the expected logs as well

Automated testing is so much faster than manual testing, with any program except the most trivial, you have zero chance of getting good quality without automated testing.

I'm really starting to hate youtube due to their long ads

@tongobong1

3 ай бұрын

@luke5100 don't be silly. Great developers are mostly underpaid and their jobs were taken by bluffers that are good speakers with very high self esteem and usually below average knowledge of coding.

@tongobong1

3 ай бұрын

I am a part owner of KZread - I own shares in Alphabet the 100% owner of Yutube and I give apology to anyone that is disappointed with the service that is getting worse. We should tell KZread that it is time to cut back on ads and also on censorship. One way of telling this is to install an adblocker and turn it on everytime it annoys you with ads and then turn it off to give the service another chance. Over time KZread algorithm will learn how many adds will show you.

If you only think of tests as a check box someone has forced you to check to be "done", then yes, testing is bad for productivity. But if your goal is just to check in as much code as possible, you are doing it wrong. It's not about checking off Jira issues. Putting valuable features in front of users is what counts. Then the question is, what kind of testing, if any, makes that faster, easier and more reliable. This is where I find the biggest value of TDD/BDD (or at least similar approaches). It helps you defining what "done" means for some part of the system and it does this not as something to help you "prove" that what you already wrote is "working", but as a support for determining what code needs to be written and why. It also helps in keeping your code testable. If you write tests first, you'll probably make them simple and let the design of the code be decided by that. If you write the code first, there is a tendency to squeeze the tests until they are "green", when perhaps the code should be refactored to make it easier to test. If the code is hard to test, it will be difficult to change later on. I have sort of stopped doing strict TDD though. I usually iterate between code and test, as you will discover reasons that something could fail as you write code. I do try to keep code and test in one commit though. I might even take a first stab at something without tests, just to get a bearing on where to go, and then throw it away and start over. I also want to add something about long running tests. They are not only a productivity killer, but they can also be a quality killer. I have found that making small, incremental changes is very important for keeping quality up, regardless of what kind of testing you do or don't do. Long running tests creates an incentive for fewer changes. Fewer changes without changing scope means larger changes. Larger changes are difficult to understand, causes integration issues, are more likely to fail etc, etc. This will look like poor quality that might trigger a bigger focus on creating MORE long running tests that further deteriorates quality. Not good. Make sure you can keep the pace up or the whole project can go up in flames. Minimum move long running tests out of the pre-merge workflow.

There are things I agree with and things I disagree with in this video. Yes, writing automated tests are necessary for great software development, unit testing specifically is great. What I disagree with is when you should write the test, they should not be written before the code is written, because of Goodhearts law, i.e. “a metric turned into a utility function ceases to be a good metric”. Instead I propose approaching testing scientifically, by forming hypotheses about the correctness and then write tests that can disprove those hypotheses. While I think it would be nice if all tests were quick, I don’t think it is always possible. My background is in scientific computing and by first hand experience I can tell you that some properties of numerical routines can only be probed with large scale data. You might have a numerical unstable algorithm, that works well for the small easily tested cases, but fails as soon as you expose it to real world data. You should test your code close to expected use cases and not just some small artificial data.

I don't know if it was intentional but, the first part of this video didn't seem at all rational to me but during the second half, it all came together. It's like CD to come up with attention-grabbing titled videos. My slogan is that testing is 4x effort and 4x confidence.

good content, but a bit ironic that a typo in the word "existingn" made its way into the production video

The whole reason of testing , to build a net of safety, it helps developers to catch bugs before they managed into production and would cause real life damage, anyone who compromised with tests is not professional and i don't care if somebody have master degree or any degree when you not committed to quality for software you doing worse for everybody in your company. Some junior devs will say , but but i have solved the problem, maybe , but think about future what you write will be used in the next 5 to 10 years and later what if the requirements change and they do change what then ? We in IT industry running like fox in a wheel, but its time to think trough and be a smart owl. Pressure is real, professional developer know how to combat it, it means have guts and be honest in estimations , which is the hardest thing in software development.

@tongobong1

3 ай бұрын

Yes but you would be surprised to know how much of advice on writing good unit tests is just terribly wrong and also the best parts are completely missing from most books... For example how to determine which tests to delete when we cover the code with better/more useful unit tests...

@orlovskyconsultinggbr2849

3 ай бұрын

@ong1 ok, i too have experience with false and bad tests, the answer is to think about whether the bad test make sense to production , if the test dont test any really production feature , than you delete the test and the code which this unit test put under test. Ok , pain start here, other developers maybe depend on the bad code and probably will be unhappy about that you think to delete very important code to them. Thats where meeting make sense you speak with you fellow devs how we cans refactor the code , so that it become testable if the arguing continuous its time to stand up for the quality of code you say things like: "We can do better then delivering mess to our clients or QA!, How much time it will take us to fix it later? " If manager says to you we dont have time for fixing it right now, you say ok , so you the manager want that i do bad job and create further mess just to pass your deadline? Are you aware of consequences? Finally you say i will give honest estimates and i will take time to present those estimates to you, are we in agreement? Probably manager will be angry at you , maybe he even threaten to fire you, maybe he even say that you incompetent , but its you job as professional to stay honest about the quality of the work.

@tongobong1

3 ай бұрын

@@orlovskyconsultinggbr2849 no don't delete the code just the tests that duplicate testing that code. Keep the most useful tests that are a bit larger and delete small tests that are already covered by larger teste. It is better to have 10 large unit tests - that are stil unit tests and not integration tests than having 100 small unit tests.

@tongobong1

3 ай бұрын

@@orlovskyconsultinggbr2849 crazy that youtube censored my answer to you. I hope you will get this answer: You should just delete the tests that are testing the code more than one time and don't delete the code. It is better to have 10 large unit tests than 100 small unit tests that test the same code.

superb

Spend a little time now to save a lot of time later.

Sociable Unit Tests, I like it

It seems to me like 70% of all my colleagues don't care about any kind of testing (some of them don't seem to even bother building and linting to catch obvious syntax errors either before committing😅), and 20% are obsessed with test coverage so they make ridiculous tests for "everything" but end up using so much mocking that most of the tests end up just enforcing the current implementation rather than the result of the funtion: like one test I once found that called an API endpoint with a mock object and injected a mock database and verified that one function on the mock object was called 20 times inside the loop of the function. I "broke" this test when I moved the function call outside the loop, since it always returned the same anyway. And once I had spent 2 hours trying to understand that mess of a test, I realised that the only thing the test actually tested was that a for-loop actually loops and that return statements return and in the process enforcing an inefficient function call inside a loop. And all that mess of mocks didn't even make it faster because it still spun up a test database just to verify that the test database was able to write and then read the value stored. Which is not only pointless since it was a 3rd party database, but since all the mocks were enforcing inefficient loops, all of them broke when you added more tests or just reordered them because it changed how many elements the SELECT * queries returned 😂 I'm very suspicious of mock frameworks now. They always seem to inspire pointless and slow tests. I much rather manually create fakes and dummy implementations wherever they are absolutely needed. And if that makes the test impossible or pointless I see that as an indication that the code doesn't need a test at this level, or needs to be rewritten. In my mind pure plumbing functions that take some user input, maybe sends it to a validation funtion and if it's ok fires off a trivial database query, doesn't need a test. The validation function should be unit tested, and the database queries should be tested through testing the system. But it simply doesn't make sense either faking a whole database or spinning up a test database just to test that write() writes and read() reads. That's like testing getter and setters without any logic (and I think getters and setters with unexpected logic inside is a code smell anyway; and getters and setters are just a stupid way to write structs or dictionaries in a language that doesn't support them). I'm also surprised how many test frameworks are so slow to start up that even simple proper unit tests run no faster from the command line than making a development build and run the tests inside the browser. Not sure what it does but it seems like they often insist on making a full build each time an spin up all sorts of mock engines and mock databases and mock browsers despite the tests not using them.

@SteinGauslaaStrindhaug

3 ай бұрын

When I removed the assertion that the function on the injected mock object should be called 20 times, I realised that the whole test consisted of 20 lines setting up a bunch of mocks and then calling the function and verify that it ... Eventually returned? It didn't even very the results. But it still made running the tests 1 minute slower because despite the hundreds of lines of incomprehensible mocks and injections it still also spun up a local database, populated it with some "fixture" data wrote and read and deleted from it for every test anyway. And weirdest of all despite the test system reporting 100% test coverage of the API code. It still had several proper functions that was relatively easy to unit test that were actually never tested because they were bundled with a class that was always mocked! 😂 I realised this when I found a bug in one of these wondering why the supposed 100% test coverage didn't catch that... So I changed it to throw an exception and while the server now refused to even start the tests still ran fine.😅

Retesting something multiple times as QA and wasting almost a day for something that the dev could have verified by a small unit test is just,... disheartening. I wouldn't expect for everyone to "smell" every situation where a unit test is necessary. But once you get the task to fix your previous code, please spend like a few minutes to even consider if a unit test would be useful. You don't want to have to touch the same code again the next day and i don't want to have to test the same thing again. 🖖

My personal gripe is requirements changing way too much and way too fast to keep up. I'd need another extra 2-3 hours everyday to dedicate to rewriting and fixing the tests because the specifications changes.

@jasondbaker

3 ай бұрын

Sounds like a poor software culture. You’re not given the time to properly test your software because the software keeps changing. I mean, what could possibly go wrong? 😑 As an engineer, I would have ethical qualms about working in this sort of environment. Your leaders are not positioning you or your company for success.

@tylerkropp4380

3 ай бұрын

If the requirements people knew it took longer for their changes to be implemented, I suspect they would adjust to that and think more about what they actually want. It's not good to enable them.

Heyyyy, it's you! I have your book!

@TrishaGee

3 ай бұрын

Thank you!

There's another angle: Writing tests is boring. It's tedious and repetitive, especially the more you realise all the ways something can go wrong.

This video is fine, but the blatant clickbait title is not. I have enjoyed many of your videos in the past, but I am done watching videos that say the opposite of the title.

I hate tests but love assertions.

What will definitely slow your productivity down is having bugs on production because you didn't test it properly in the first place.

Honestly, after years of TDD and DDT I am conflicted. There is no doubt that having the skills to write good tests is crucial for every modern dev. It totally transforms how you think about code. But there are some bugs that you know when you fix them, this code will stay exactly like that for years to come. And if you have good diagnostic tools, you can fix it again within minutes. So, will adding a test after you fixed it add any value? Uh... maybe? So I am not that strict about it anymore. Have a close look at your bug rate, and if it starts to pile up, rethink your test strategy.

@ContinuousDelivery

3 ай бұрын

I prefer not to test it after I have fixed it, I prefer to write the test as part of fixing it. I want a test that demonstrates the bug, before I write the fix. This approach avoids the problem that you describe here.

Hands up...I know nothing about the subject. I haven't a clue what you are talking about (why am I watching?) But I am sure that Boeing would agree with you.

Testing isn't bad for developer productivity, however change request are Writing code and tests at the same time with a lot of change request is bad for developer productivity, because you always have to rewrite code and test at the same time increasing the amount of work done. That is why most companies have a team for testing or QA team, because it is more efficient way of shipping software to production The problem with these TDD advices is there aren't specific for what type of software is developed and developers don't have a lot of time for testing UT that can run quickly are good when you develop library, however if you have CRUD application there is very little code to do UT that run quickly. CRUD applications can greatly benefit from testing for every SQL query, but those tests aren't fast and easily to write because it need more up-front setup and TDD advocates are hiding this fact, because most of their advices are useless for CRUD applications That is why TDD is failing for the last 20+ years, useless advices for the majority of the software that is produced

I've tried the TDD workflow a few times, but overall I just find writing tests to be either mind numbing or excruciatingly difficult. Sometimes counterintuitively both at the same time. My mind is only able to produce two kinds of tests, trivial ones that cover lines but don't actually provide any value. Or ones that take days to setup because they require spinning up VMs, creating gigabytes of test data, and then producing complicated logic to actually validate the results. . Well, and all of this effort goes down the drain, when two weeks into development, the PMA radically changes the requirements and the project ends up heading in a new direction. . Does anyone have some good sources on how to write tests for services that dominantly rely on black box services provided by 3rd parties? I only see mocking as an answer, but at that point the tests lose any value, because I need to know the program works with the real thing, not with my ideas about it.

@_Mentat

3 ай бұрын

I have tried TDD. There is a fundamental flaw in its philosophy. The user only decides what they really want when they see the software running, i.e., you have to write the code first, then demo it, then test it. TDD violates Agile.

@jasondbaker

3 ай бұрын

Properly built mocks can support reliable testing patterns. World class engineering organizations do this. I’ve used mocks to test software that impacts people’s lives. You can never truly test against the real thing unless you do all your testing in production.

@Bozebo

3 ай бұрын

I do not have good sources on that, it's a tough real world problem of communication between the actual parties and goes outside the tech itself :) So you have to engineer against the unknown robustly at every step imaginable and with as many logs as possible (both of which you want anyway except in niche high performance cases) if they don't have a sandbox, and then sometimes what you would've had to log because of how bad the API is is inherently sensitive too ugh. I've had to use APIs dealing with other people's money that had no sandbox and bad/outdated documentation, had to send them corrections to their own documentation...

Any practice done sufficiently badly destroys productivity

Werent you using pair programming to prevent any bugs, and committing straight to master without any automated testing? Just ship it and let it all work itself out, scro.

Anybody have a TDD guide for old farts who still code like it's 1999? I tried to get into it a couple times. I understand the basic concept but my mind goes fully blank when thinking about what test to write

@_Mentat

3 ай бұрын

Don't bother, it doesn't work in the real world.

@RT-.

3 ай бұрын

​@tCan't be true when people like Dave have proven it can work very well... Two of my favorite examples are Minecraft and Sea of Thieves for example. Yet... I can agree, it might not be entirely all that useful for small teams. I wasn't successful in getting a good experience with it (as in, helping me that much), but that doesn't mean I think it can't work. It just means it doesn't fit my situation, or I have been doing it wrong. I wouldn't say these overly polarized opinions help..

@gimballock2084

3 ай бұрын

I would say, when you need a class, think about what the responsibility of the class should be. Then write down what requirements need to be fulfilled to live up to that responsibility. Now you basically have the names of your tests, all those requirements. Write the tests, then write the code. Avoid implementation details in your tests and requirements.

@harrypehkonen

3 ай бұрын

Step 1: Write a function that takes an argument and gives you a result. Step 2: Write a test that calls that function with a known argument, and makes sure it gives you the correct result. Step 3: Repeat step 2 for all edge-cases. After doing the above a few times, you may see a different way to write functions so that they are easier to test. You may even find ways to write the tests first.

@ThomasFiniHansen

3 ай бұрын

I once saw a video where someone demonstrated TDD by first writing the first test that checked that if the function got "this" argument, then it should return "that" argument, and then making the test green by simply adding `return "that";`. Which seems pretty stupid at first glance, but when you then add more tests, you replace the return with more appropriate code, but you still have that first test checking the basic case. I've found that this altering between thinking up the next test case and this laser-tight focusing on making the tests pass works well. When you're writing the test you're thinking about how you want to use your thing (and not how to implement it), but when you're writing the code you're focused on the one thing you just wrote a test for (and not all the other things you've already thought might be handy at some point). You shouldn't think "how do I want to test this?", you should think "how do I want to use this?"

Tests are proof that your code works. On every delivery.

@Bozebo

3 ай бұрын

Well, good tests are :P

Poor requirements are bad for productivity

Total B.S. … unless you think your developers write flawless code and handle exceptions well within their own code, there will ALWAYS be data breaches & costly outages with damages too widescale to estimate. A case in point is Amazon’s outage lasting for over 1 hour on Feb 15th because someone broke its ability to maintain user credentials between servers. Vit’s easily possibly they lost at least $10MM in revenue because someone didn’t test their code in managed stages, and it’s foolish to think it won’t happen again, or that “break early & break often” is a valid approach for essential systems. Utter crap.

@pillmuncher67

3 ай бұрын

I have no idea what you're saying? Should we test? Shouldn't we? How can we trust your code if you can't even express yourself properly so everybody can understand what you're saying?

Example based testing is not that useful, actually it is useless most of the time. Property based testing, metamorphic testing and mutation testing are what makes testing effective and valuable.

@ContinuousDelivery

3 ай бұрын

They are VERY different things, PBT is an "after the fact" testing approach, example based testing is a design approach. I don't think that design is useless, unless it is very bad design, and the point of clearly specifying what should happen in each example of use is the best way I know to avoid bad design.

@ibrahimkoz1983

3 ай бұрын

@@ContinuousDelivery I disagree. Property-based testing (PBT) encourages algorithmic thinking, leading to better design. This is because it helps reveal what's important during testing and allows you to ignore irrelevant details. Last but not least, programming languages are not as expressive as needed to convey design. They belong to the solution space. If you aim to express your design clearly, you should consider formal methods. You can check out TLA+. TLA+ operates at a higher level of abstraction, enabling you to convey your thoughts and design process much more effectively.

1. Don't remember what is the code suppose to do, 2. Don't know why it works this way, 3. Don't know which trad-offs made or why. All these questions have ZERO relevance to write test for your code. Unless, you are setting up a facade of testing activity. This is how you kill a patient in certain industries. As a professional, if you don't have time to really test your pink illusions and code, don't code. Find something else to-do. At least you will not harm us with this stupidity.

@user-bk9wt8gk1q

3 ай бұрын

Developing and testing machinery that is used in medicine has way stricter conditions, rules and guidelines than some small notes app or an onlineshop. I would hope MRIs used today don't rely on undocumented legacy code.

@cheaterman49

3 ай бұрын

Therac 25 was probably not the last... But we really don't wanna know as patients hehe

@ron_pe

2 ай бұрын

@@user-bk9wt8gk1q Thank you. Question, legacy code is by definition bad code? Or undocumented code? Or maybe, the code is "self-documented" enough? The code and the documentation will never "tell" us how it is going to fail. The only way to know if our code is good enough is by critically thinking about it and testing for it. No infinite amount of unit testing will ever help you sort this issue out. The real problems emerge when there are orders of integrations and interactions, for example 2 distinct variables/classes and 2 different inputs. For testing medical devices we usually expend the field to 5-7x5-7 combinations parameters and inputs to outputs. Even then, sometimes its not enough and you need a human brain in the loop. In the medical industry companies must document their solutions, the development process and testing sufficiently enough. Otherwise, they will be out of business.

@user-bk9wt8gk1q

2 ай бұрын

@@ron_pe Tests for medical appliances need to be documented in a way so that they can be recreated 1to1 years later if it needs to be (e.g. if a patient gets harmed by the machine). That's why your "this will kill a patient" doesn't make that much sense as a comment to this video. Creating software for these machines is just a very unique situation to be in. It's exponentially more demanding. You can't hold these standards to all other software or else nobody would be able to afford a smart phone and no company would have their own online shop. It would not be economically viable. Also nobody said that unit tests should replace integration tests, system tests, end-to-end tests or any other form of testing. Aslong as people are not geniuses and/or we get infinite time to develop, we will need multiple steps in our pipelines to ensure we build the right in thing the right way. Legacy code is, to my knowledge, not well defined and often misused. If tdd is your thing you will say "any code without automated tests or bad tests is legacy code". I think the description that fits it well is "valuable code, that nobody really wants to change / people are afraid to change".

@ron_pe

2 ай бұрын

@@user-bk9wt8gk1q My comment makes a lot of sense to this video. The creator did not put a disclaimer, this method is only for software build for the marketing industry. If your testing solution does not take into account the "extreme cases" than your solution is wrong. Yet again, this is fixating about the unit not the problem. An addiction of the software industry. What about the Automotive industry, the banking or financial industries. Would you accept a solution from a vendor in this industries with only unit tests? What about all the supporting industries developing tools for the production of tools for the former industries? Would you accept a security product that fails to uphold to its claims since the vendor only unit-tested their anti-malware solution? Would you buy a product from an On-line store that was not sufficiently tested and can be easily hacked, stealing credentials, credit card, personal information... I can go on. Unit tests are not sufficient testing for these cases, and there are more. This is how I understand this video. The author implicitly suggests that since testing takes time therefor eliminate all testing activities that take "too long" to complete. "Too long" is undefined. So, what is left is simply automation - the Unit test. There is no such thing as a free meal in the universe. Garbage in with a Minimal work equals garbage out. Last note; Test your solutions sufficiently, the keyword here is sufficiently. What is sufficient? deduced based on budget and risk.

I personally agreed with most of the statements here. Most of us have already been hurt by some legacy code without tests, but I can't agree with: "treat test as the first class citizen". In the end, we have to deliver value to our application and add functionalities, not tests.

@jasondbaker

3 ай бұрын

We write tests to delivery new functionality and value in a manner which reduces risk. I’m not delivering net value if I release new functionality which causes another part of the system to fail. Most customers tend to value software reliability more than new features.

@KrustyBox

3 ай бұрын

​@@jasondbaker I believe you explained your point better than me. I was trying to say that, the new functionality should be the first-class citizen. Tests are very important and work as a guardrail for delivering high-quality and maintainable code. Still, tests are one perspective of coding.

OMG testing is a quality assurance activity. Testing assures that the product performs according to requirements. You can list the disasters caused by the incorrect assumptions designers made and who then wrote tests that only served to validate their incorrect assumptions. Developers tend to have the attitudes shown by this presenter: and so always, testing should be defined and documented in advance of coding and then it needs to be conducted or at least observed by independent persons. The independence of quality assurance is something essential that is being continually eroded. BTW testing should not be seen as an overhead and always the project plan should have separate tasks for all levels of testing. The Development Managers are capable of exerting pressures of all different types on developers to skimp or even omit testing. The independence of quality assurance ( and I mean that they do not report to the development Management but there is a quality Director they report to.) gives us a much better chance of catching design errors.

@Bozebo

3 ай бұрын

I think you're conflating different types of testing into one. Developers write tests to structure the model of the problem itself simplified down into the necessary moving parts (no not the code implementation of those moving parts, the parts themselves), it's at the same time as development and makes development easier at scale and, in my opinion, is part of technical documentation. QA testing addresses the wider process is fit for purpose in actual use. Integration testing I would agree is dangerous to prefer in advance of actual development though in some problem landscapes it could be fine (basically, if the project is pretty "easy" and everyone knows what they're doing and the design is good and it can be waterfalled. Structural engineers know how to test structures before they build the thing and they're all different structures, same thing although in this case you can easily non destructively test all the software at all times so do it). But there's another with stability and security testing, which is more on development side. I would honestly say it should all be everyone's responsibility (TQA) because different focusses know how to test different parts better, but of course there needs to be an indepentent QA as well as you'd also want in industries that don't have other kinds of internal testing to confuse the two.

@mikebell9983

3 ай бұрын

@luke5100Thanks for your perspective Luke. I'm from the 1980s alright! You say you don't do waterfall anymore (a negative statement) what exactly is the modern way?

First Comment BOOM!

Remember, tests have zero value until they discover a bug. Even when a test discovers a bug, the cost of the bug may be small, and the cost of writing the test still a net negative. I know people who are mad for tests - they have wasted the company a lot of money. I have written hundreds of tests and whenever they failed it was always a problem with the test, not the program logic. I do actually test my software though! I prefer a battery of tests from a test harness prior to release rather than coding in tests. That way you run the tests once near release, not every time you do a build.

@leerothman2715

3 ай бұрын

And how many times do you release then? Only running test before release will result in a slow feedback loop. Sounds more like waterfall than agile.

@_Mentat

3 ай бұрын

@@leerothman2715 It's 2 to 3 releases a year.

@_Mentat

3 ай бұрын

@luke5100 I am working on a really terrible legacy code base; a mixture of Assembler, C, C++, C#, Java and JS dating back to the 1980s in parts ;) As a developer I do endorse paranoia though. If there's a risk someone might put bugs in your code then you need to protect yourself. However, I'm also on a tight budget and code written needs to come back as £s in the bank or I don't get paid. The airy fairy nonsense starts when people have too much money!

@leerothman2715

3 ай бұрын

⁠​⁠@luke5100What specifically do you have an issue with? To answer your questions I’ve been writing software for over 35 years. I work in a team that practices TDD, pair programming and CD so I think that they are good practices for software development?

@leerothman2715

3 ай бұрын

@luke5100apologies I miss read your comment. I’ll now Stand down 😜

Testing is the only programming related job humans will get in a near future

@rfphill

3 ай бұрын

Meh...

Maybe leave these questions to developers champ

@ContinuousDelivery

3 ай бұрын

Why? Doe the Medical profession leave washing their hands before surgery to the surgeons? Do pilots leave the decision about the takeoff speed to each pilot? Of course not. Having guidelines is how professions establish standards and improve.

@rockenOne

3 ай бұрын

@ContinuousDelivery onya kiddo, maybe learn the profession before trying to dictate. Do the work, then you will be welcome to join the table. Otherwise, all you are is a cheezy click bait youtuber.

@ContinuousDelivery

3 ай бұрын

@@rockenOne You think I haven't paid my dues as a dev? 🤣🤣🤣

@rockenOne

3 ай бұрын

@ContinuousDelivery I am just being honest. there is no need to get emotional bud.

I agree with the general idea in the video, but there are subtle errors. Bring back Dave back.

@trumpetpunk42

3 ай бұрын

I didn't hear anything particularly incorrect

@danielwilkowski5899

3 ай бұрын

@@trumpetpunk42 I bet that Dave would never say that executable specifications are "being run by our CI server" (at4:44), Dave would say "run it locally".

@Matfen815

3 ай бұрын

​@@danielwilkowski5899 Depends what kind of tests, right?

@trumpetpunk42

3 ай бұрын

@@danielwilkowski5899 did you mean 5:45? Because she pretty much says exactly that