Wow 😲

It's not that hard to setup GitHub or GitLab to make sure all the unit tests run for each PR.

If you use something else for version control, check if they offer a similar CI feature. If not, setup Jenkins.

I'm an SRE at a big tech company, so part of my job is to make sure CI infrastructure is readily available to our Dev partners. But I've worked at smaller companies before (10 or less SWEs) and even they had a Jenkins instance.

This is a bright red flag to me. If I worked for a company that didn't have CI, the first thing I would do is set it up. If I wasn't allowed to take the time required to do that, I would quit...

Automated testing is often more cost effective than manual testing. Not to say 100% automated testing is a reasonable goal. But I’ve never worked anywhere without some automated testing (unit, integration or end-to-end).

I'm on a similarly sized team, and we have put more effort into automated testing lately. We got an experienced person in on the team that knows his shit, and is engaged in improving our testing. But it's definiely worth it. Manual testing tests the code now, automated testing checks the code later. That's very important, because when 5 people test things, they aren't going to test everything every time as well as all the new stuff. It's too boring.

So yes, you really REALLY should have automated testing. If you have 20 people, I'd guess you're developing on something that is too large for a single person to have in-depth knowldge of all parts.

Any team should have automated test. More specifically, you should have/write tests that test "business functionality", not that your function does exactly what it is supposed to do. Our test expert made a test for something that said "ThisCompentsDisplayValueShouldBeZeroWhenUndefined" (Here component is something the users see, and always exepct to have a value. There is other components that might not show a value).

And when I had to interact with the data processing because another "component" did not show zero in an edge case. I fixed the edge case, but I also broke the test for that other component. Now it was very clear to me that I also broke something that worked. A manual tester would maybe have noticed, but these were seperate components, and they might still see 0 on the thing that broke becase they had the value 0. Or simply did not know that was a requirement!

We just recently started enforcing unit tests to be green to merge features. It brings a lot more comfort, especially since you can put more trusting changing systems that deal with caluclations, when you know tests check that results are unchanged.

automate everything is the standard practice. You can't get a pull request in my company without automated code review including unit tests and selenium style practical tests plus two human reviewers.

I've never worked (recently) at a shop that didn't do some level of automated testing. In terms of having a bunch of people working on a big codebase without stuff being randomly broken most of the time, I'd say it's an absolute requirement to do it to at least some passable level.

In my experience it's, if anything, sometimes the opposite way -- like they insist on having testing even when the value of it the way it's being implemented is a little debatable. But yes I think it's important enough in terms of keeping things productive and detecting when something is totally-broken that you need to.

(Especially now when you can literally just paste a module into GPT and ask it to generate some sorta-stupid-but-maybe-good-enough test cases for it and with minimal tweaking you can get the whole thing in in like 10 minutes.)

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!

Very common. Your coworkers are either idiots, or more likely they're just being lazy, can't be bothered to set it up and are coming up with excuses.

The one exception I will allow is for GUI programs. It's extremely difficult to do automatically tests for them, and in my experience it's such a pain that manual testing is often less annoying. For example VSCode has no automatic UI tests as far as I know.

That will probably change once AI-based GUI testing becomes common but it isn't yet.

For anything else, you should 100% have automated tests running in CI and if you don't you are doing it wrong.

Here’s my random collection of thoughts on the subject.

I have no idea how common it is in general. Seems like some devs build tests while others don’t. This varies plenty on a team level as well as organization wide. I’ve observed this at small to very large companies, though not FAANG where I generally hope and expect that tests are a stronger standard.

I will say that test are consistently and heavily used in every large, open source project that I’ve reviewed. At some point, I think quality test cases become a requirement.

Here’s the big thing. Building automated tests is almost always a wise investment, regardless of the size of the org. Manual testing is dramatically more expensive and less effective than running unit and integration tests. I’ve never written unit tests and not found issues.

More importantly, writing unit tests forces you to write code that can be tested. This is important. IMO, code that can be tested is 1) structured differently and 2) almost always better.

Unit tests protect you from your own mistakes. Frequently. Integration tests protect you from other people. E.g when your code depends on an api and that api unexpectedly introduces a breaking change.

Everybody likes having quality tests. Nobody likes writing tests.

Quality tests are basically a strict requirement for fully automating ci/cd to production. Sure, you can skip tests and automate prior deploys, but I certainly don’t recommend it. I would expect people to be fired for doing this.

Chasing 100% test coverage is a fools game. Think about your code, what matters, and what doesn’t. Test the parts that add value and skip the rest. This is highly related to how writing unit tests change your code.

Building front end tests is inherently hard. It’s practically impossible to fully test front end code. Not even close.

Personally, I like the idea of skipping tests when you’re building a POC. Before the POC is done, you may not know if your solution is viable or what needs to be tested. The POC helps you understand. Builds tests for MVP and further iterations.

Quality ci/cd tests are complimented by quality observability, which is a large and independent topic.

/ ramblings of a tired mind

I'm in a team of 4 developers and we demand automated testing. Ok that's part of a slightly bigger development team but even our QC team have automated tests that they run for integration testing.

And please for the love of all that is holy.. DO NOT let some smuck go through setting up a test platform with all defaults and cause thousands of notifications per minute without any plan on actually addressing notifications (by either actually fixing the issue or tweaking thresholds for your specific situation.)

Else all the system does is train people to become apathetic to notifications and warnings. I once was on an IT Team that had read notification boards and 104k notifications.. and all they did was joke about it.. seriously.. turn off the system then.

I wouldn't accept a job if they didn't do it.

We use automated testing, not for full coverage, but smoke tests so we can detect problems more quickly and avoid potential embarrassment.

Sometimes you'd use defensive programming (type checker, exception handling, null safeguards, fallback/optional values) which can be argued as a sort of in-place testing, so testing can be not as beneficial to your projects' robustness as the readability of their core business logic. And some languages would lean more heavily towards defensive programming (e.g. Go, Scala or well written Typescript) and some would rely more on tests but also be designed in a way that makes testing really easy as they seek to keep things loosely coupled (Elixir or Clojure).

Also if your language doesn't have a quality REPL to reliably test things manually, there is a relatively high chance you debugging process is causing you to waste more time than having a good test coverage.

I worked at 8 different companies as a contractor, so hopefully my sample size is big enough to be meaningful. I'd say it's 50-50. The companies that don't, usually know that they should but they need a little help. Companies that don't do it and they think they don't need it, are becoming more and more rare (fortunately).

Stick with it. If you're a junior, don't go evangelizing automated testing because it will fall on deaf ears until you're a little more experienced. Keep practicing and offer to set things up if they haven't already.

We started focusing in on automated testing when we had 3 manual QAs (not including me), and since then every new project has started with plans for automated testing.

It's important to note that we don't do automated tests instead of manual testing. Manual testing is still important for focused review of new features/bugs, but automated tests make sure code changes aren't breaking anything elsewhere.

Also this is all about end-to-end tests (with Selenium, in our case). If you're talking about a lack of unit/integration tests within the codebase itself, that's a huge red flag. Even if quality issues aren't the end of the world, they will definitely make people reconsider using your product. Who wants to trust their financial information with unstable software? It's also making your QA team less efficient since they're having to chase down issues that would be better recognized by the dev who wrote them.

Automated tests are pretty common, yes. It's not strictly speaking a matter of company size, but moreso company technical maturity.

Automated tests do not slow your business down, it is in fact the only way to not get slowed down as the amount of code you maintain increases.

The alternative cost of not having tests catch issues before they reach production is very significant - an error caught by an automated test costs nothing, while an error that makes it into production can cause immense harm to the business, if only for the time necessary to remediate the issue, which is time that could have been spent on actually making progress on delivering new features.

Not to mention the high cost of having to employ increasing amounts of manual testers just to keep the worst of issues from slipping through.

All in all, not having automated tests in place is a significant mistake from a business perspective. You might want to have a frank discussion with your CTO about it.

My context: I'm in a small ~30 software company. We do various projects for various customers. We're close to the machine sector, although my team is not. I'm lead in a small 3-person developer team/continuous project.

I write unit tests when I want to verify things. When I'm in somewhat low, algorithmic, coding behavior, interfacing areas.

I would write more and against our interfaces if those were exposed to someone or something. If it needs that stability and verification.

Our tests are mainly manually (mostly user-/UI-/use-interface-centric), and we have data restrictions and automated reporting data consistency validations. (Our project is very data-centric.)

it’s not practical for our size and the business would allow us to slow down for that

Tests are an investment. A slowdown in implementing tests will increase maintainability and stability down the line. Which could already be before delivering (reviews, before merge or before delivery issues being noticed).

It may very well be that they wouldn't even slow you down, because they could lead you to a more thought out implementation and interfacing. Or noticing issues before they hit review, test, or production.

If you have a project that will be maintained then it's not a question of slowing down but of are you willing to pay more (effort, complexity, money, instability, consequential dissatisfaction) down the line for possibly earlier deliverables?

If tests would make sense and you don't implement them then it's technical debt you are incurring. It's not sound development or engineering practice. Which should require a conscious decision about that fact, and awareness on the cost of not adding tests.

How common automated testing is - I don't know. I think many developers will take shortcuts when they can. Many are not thorough in that way. And give in to short-sighted time pressure and fallacy.

yes, it's very common in my region. 50% of companies I worked at had CI servers that ran unit tests round the clock. the companies are only slightly bigger than yours. also i know multiple companies my company worked with also have CI setups.

some even auto deploy to prod when the tests in master passed okay.

most use hudson or jenkins for CI with junit, phpunit, selenium and/or cypress for testing.

I wish. Most companies i've worked at i was maintaining monolithic legacy code that's hard to test properly. Sometimes another team was developing the next best thing under management guidance (so it would become the next monolithic legacy code) but usually no.

I've only worked at one company that did TDD and things were smooth.

As usual, management only sees short-term and it's hard to impress on them that any time lost now by implementing proper testing will be gained in the long run.

Testing? What's that?

Yes, it's pretty standard, although how valuable it is depends on a lot of factors. You can write a lot of useless tests just to get the expected "coverage". Also management will never see value in that type of work even after things break in production.