How often do you test your code.

Question

When I look at complex programs ie facebook and the millions of lines code I wonder how regular you would test to see if their is any bugs. You would not want to finish a web form for example then move onto the next form only to find out their is buys. Is their a general rule of thumb here?

Answer 1

I really don't know about facebook but I often make little mistakes and typos in my little codes ;)

Sometimes I notice them myself and sometimes my followers do. I would say at least twice after my code is published :)))

Answer 2

there's no general rule of testing your code. all the programs which I made throughout my journey required me to test the program with every single change i made to make it work right.
if I use a random function, that would require me to test it a lot of times to ensure everything is working fine.

Answer 3

With something public and as big as Fb, opening a door for bug hunters, testers may help point out bugs. And of course users feedbacks has their points too.

Answer 4

I test all the time. Sometimes, writing the tests and making sure they all pass takes quite a bit of time but it's worth it.

In a good company with enough resources, you would have different types of tests you need to do. A lot of them are automated but you will also have manual testers (QE/QA). These are some of types of tests:

Unit
Functional
Integration
End-to-end
Smoke

As I'm developing, some or all of the automated tests will be running all the time, watching for changes in the code. So, I fully expect some tests to fail when I put in a new feature. That's a good thing.

I then fix the tests which might include adding new ones. Sometimes we do test-driven development (TDD) which is when tests are written first. This works well for unit tests, but not so well for other types like end-to-end.

Also, before my work can be accepted, automated tests run on the cloud. This is part of our Continuous Integration (CI) process but lots of companies have something similar.

Answer 5

I run unit tests before every git commit and whenever I feel like running them. These test individual functions.

More complex tests like integration tests run before every deployment, as they take longer and aren't done in a few milliseconds.

Unit, integration and even end-to-end tests are automated.

Usually you'd deploy into test environments first where the QA people can test your software in a "live" setting before going actually live.

That's how I imagine proper software companies do it. Where I'm at we implement this to varying degrees but most of the code we own we test manually with some automated unit tests if the dev felt like implementing them.

There is a common practice called test-driven development where you define tests before you even write the actual code you are testing.

Answer 6

CamelBeatsSnake,
Do you WfH during this pandemic?
Just asking cause Idk how its like in large companies and so I wonder whether or not the tests can be done remotely ...

Answer 7

CamelBeatsSnake,
Big Thanks,
And yes that cleared up my doubt completely 👍

Answer 8

Ipang Yeah, I've been working from home since April last year. We run local tests as you're developing but every time you push a change up to your feature branch on GitHub, automated tests run. So, the "cloud" makes it possible for us to test remotely. Then, once your change has been reviewed (pull request review), tested and approved by other developers and testers, it gets merged into your main branch. At that point, more automated tests get run on the cloud.

This is all before a release happens. More tests run when doing a release.

We use technologies like GitHub, Jenkins, and Azure (some others too) to do this kind of thing.

We also have manual testers who test our code against what we call our QE environment. It's a staging environment which mimics the production environment.

Everyone in our company is working remotely at the moment, so it's possible to do this kind of thing remotely. Hopes that answers your question.

Answer 9

Ipang Cool, glad to hear that. You're welcome.