TLDR; I am giving a presentation on unit testing and TDD. I would like to know your opinions and experiences with automated testing.
I practice te...
For further actions, you may consider blocking this person and/or reporting abuse
I'm going at this from the angle as a software tester, so my opinion might differ slightly. :)
Whenever we deploy a system or the whole chain, we do sanity checks manually to make sure our core components are not affected by the release. If they are, rollback and cry. It consumes a lot of time and we have testers that have to be at the ready at 3am or something for these tests...
However, when there are automated tests in place (which some of our systems have), we can use the CI/CD pipelines to trigger the sanity checks. No need for human interaction, and also a lower risk of human error.
The same goes for regression tests, which can be used in even more situations. Regression tests (closest to the unit test, but from a functional pov) can be run at any moment, after any change. So, whenever you're merging branches, you can always run the regression tests. Does everything still works like it's supposed to! Awesome! Do we have failed tests? Rollback and cry again (and of course analyse where that little bug is at).
I can keep going like this, but these are some of my main arguments when it comes to automated testing.
Oh, and one last argument: when you're unit testing your code, you reduce the chances of that one hecc of an annoying tester being at your desk time and time again. ;)
Do I have your permission to use this quote and your profile picture/info in my presentation?
Of course! Feel free to use it. ^^
Thanks for the different perspective, Rose! Rollback and cry was cracking me up 😂 I'm going to use that from now on!
Your unit tests are only ever going to be as useful as the person writing them, and the underlying code being tested in the first place.
They are not a silver bullet or a quality guarantee in your software.
Now, to discuss what I personally feel is the most valuable aspect of automated testing (specifically in the case of unit testing): test-driven-design.
This is a fairly radical restructuring of how you write code, by forcing you to write in a style that prioritizes understanding your execution as a series of inputs and outputs.
It encourages better software design by enforcing SOLID principles, with a heavy focus on SRP (single responsibility principle).
Writing software in this way naturally makes your solutions more resilient, with the added benefit of having automated tests to reinforce that.
I totally agree! I am a huge advocate for test driven design as well. Thanks for your input!
Do I have your permission to use this quote and your profile picture/info (excluding email) in my presentation?
Sure thing, go nuts.
Hi Steven.
I started a discussion some years ago about problems with "real world TDD". Through that, I gained some interesting insights, why some people don't do (or even like) TDD in their daily work.
What were your problems with "real world TDD"?
Lars Richter ・ Oct 30 '17 ・ 1 min read
Some of the points are:
Maybe you can use (and disprove 😄) some of that in your presentation.
It makes use of that computers are really good at: doing the same thing in exactly the same way with high precision and speed, and it will not get bored, lose interest or attention.
Humans are not able to do this. They are slow and inconsistent. Then they get tired, they get slower and more inconsistent.
So while the computer can continuously run tests to verify the proper working of software, the humans can focus on the things computers are not good at: solving problems and improving previous solutions.
Yeah that's a great point! I don't think about that aspect enough. Thanks!
That's one of my favorite benefits! Thanks for contributing!
I was lazy about unit testing because there's not an official framework for C and I thought I had to write a test for every component in my project.
You can do unit testing without a framework. Regular functions calling and checking on what you need to test, will do the job. You don't need to test everything, this is particularly true working with legacy code. You just need to modify your program so you can test a major feature without depending on a host, a peripheral or a user input. This is a good way to understand the code, and to see if that new code you just inserted don't break anything. Also this is a good way to start your tests base if you don't have one. New features and reported bugs may need you to go deeper in the tests, but only then you will write tests to verify your solution, your tests base will grow over time.
If you have a good tests base, then you can do refactoring in the safest possible way. Also a good tests base is the best documentation your code could have.
As I just commented in Ben's "come back to it later" post, not killing astronauts with buggy calculations which could turn rockets into missiles.
Do I have your permission to use this quote and your profile picture in my presentation?