@leonardogalani3151
This is a huge favor to the entire QA community :) Thank you!
@orderandchaos_at_work
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.
@michaelpastore3585
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.
@davetoms1
Thank you, thank you, thank you! "I don't have time for testing" == "We need to improve how we spend time testing" Great video!
@RichardCasemore
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.
@pauldanielmooney
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.
@dejangegic
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
@tongobong1
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.
@Ungureanui2000
In my experience, most people who criticize writing tests haven't written a single unit test in their life.
@chauchau0825
one thing people often skipped is that writing testing is only possible ifdevelopers are capable of writing testable code
@MrMate12345
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.
@nijolas.wilson
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.
@SeRoShadow
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
@albucc
If you don't test now, you will have to debug (a lot) later. It is as simple as that.
@RottenMuLoT
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
@dinov5347
Finally a realistic approach to testing rather than the dogmatic message on testing from Dave. Great video/explanation Trish.
@TheJimNicholson
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.
@Akhbash
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.
@lan_e_brezhoneg
I'd love more content on testing, also it would be great to add references on the topic. Anyway, good video !
@ErazerPT