Ask Experienced Devs

1233 readers

2 users here now

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

Ategon

Possibly stupid question: is automated testing actually a common practice? (self.ask_experienced_devs)

submitted 6 months ago by yournameplease to c/ask_experienced_devs

60 comments fedilink hide all child comments

Referring more to smaller places like my own - few hundred employees with ~20 person IT team (~10 developers).

I read enough about testing that it seems industry standard. But whenever I talk to coworkers and my EM, it's generally, "That would be nice, but it's not practical for our size and the business would allow us to slow down for that." We have ~5 manual testers, so things aren't considered "untested", but issues still frequently slip through. It's insurance software so at least bugs aren't killing people, but our quality still freaks me out a bit.

I try to write automated tests for my own code, since it seems valuable, but I avoid it whenever it's not straightforward. I've read books on testing, but they generally feel like either toy examples or far more effort than my company would be willing to spend. Over time I'm wondering if I'm just overly idealistic, and automated testing is more of a FAANG / bigger company thing.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 14 points 6 months ago (14 children)

My team follows test driven development, so I write a test before writing the feature that the test, well, tests.

This leads to cleaner code in general because it tends to be the case that easy to test code is also easy to read.

On top of this fact, the test suite acts as a sort of "contract" for the code behaviour. If I tweak the code and a test no longer works, then my code is doing something fundamentally different. This "contract" ensures that changes to one codebase aren't going to break downstream applications, and makes us very aware of when we are making breaking changes so we can inform downstream teams.

Writing tests and having them running at PR time(or, before its deployed to production, if you're not using some sort of VCS and CI/CD) should absolutely be a part of your dev cycle. Its better for everyone involved!

[–] hollyberries 5 points 6 months ago (13 children)

Doesn't this rely purely on the fact that the test is right?

[–] RonSijm 1 points 6 months ago

Sure, but testing usually purely relies whether your assumptions are right or not - whether you do it automatically or manually.

Like if you're manually testing a login form for example, and you assume that you've filled in the correct credentials, but you didn't and the form still lets you continue, you've failed the testing because your assumption is wrong.

Like even if the specs are wrong, and you make a test for it, lets say in a calculator Assert(Calculate(2+2).Should().Equal(5) - if this is your assumption based on the specs or something, you can start up the calculator, manually click through the UI of the calculator, code something that returns 5, and deliver it.

Then once someone corrects you, you have to start the whole thing over, open up the calculator, click through the UI, do the input, now it's 4, yay!

If you had just written a test - even relying on a spec that was wrong, it's still very easy to change the test and fix the assumption.

Also, lets say next sprint you'll have to build a deduct function in the calculator, which broke the + operation. Now you have to re-test all operations manually to check you didn't break anything else. If there were unittests with like 100 different operations, you just run them all, see they're all still good, and you're done

load more comments (12 replies)