Hennies I need your assistance!
My boss has put me in charge (wow yes I was surprised too) of figuring out what a good solution to our current testing nightmare would be. Therefore my questions for you are:

What kind of testing strategy do you work with at your job? Do you use any tools for it? How's the division of unit tests/service tests and/or UI tests?

I'd really appreciate you guys' input on what works (and what doesn't, in case you're living a nightmare with testing daily)

I'm a fresh dev so not too much experience.

From what I've seen we test on three-ish levels
- unit tests
- software tests, tests about the software itself, but from the outside interface and not on unit-test level
- system tests, the entire system (with hardware, I'm in embedded) is tested. This one overlaps with the software tests a good bit. Automating these isn't that easy, because hardware.

I know that some business solutions are around that manage all of that with git integration, like Jenkins.
I haven't used them myself and I'm not sure what other projects at my place use, but from my perspective they seem super complicated.

I'd personally just prefer a hook that runs a shell script in every pull request/commit.
I'm sure git services like GitHub or gitlab expect some specific format for test reports to integrate them into themselves. Like only allowing a PR to be merged if all tests pass.

At the big company I joined months ago, we use a bunch across the testing pyramid, from unit tests running in CI checks to PACT testing (although we don't do those yet on the team I'm on) going through integration tests that are checked in pipelines. There are also E2E tests that are behavioural and using the Gerkins approach that look at the acceptance criteria of user stories.

Most tests are automated and managed by pipelines within our GitOps infrastructure. But we also have a QA team that does manual tests, looking at performance and a bunch of other typical QA tests.

Ideally you want a good suite of unit tests covering all your non-boilerplate code paths, and a good suite of integration tests covering a wide range of scenarios (both standard & corner case - and it really pays to spend time figuring out those corner case scenarios.) All these tests should have to run & pass before any new code makes its way into master (all automatic.) And this has implications on the structure of your code - no-one seems to talk about this, but your code has to be structured to *allow* unit tests to operate sanely. If it isn't, then that's your first task.

There's then a top layer of tests with human involvement - you may have a QA team for those, or you may be required to do them yourself. You should have a strict testing plan of exactly what tests are required in what situation, and you should stick to this thoroughly. Exactly what's required here differs - if you're talking about a backend service, then it may need nothing more than a sanity check. If you're talking about a front end component, then (for major releases) you'll probably want a larger degree of human involvement checking all is ok.

The key point though is that the earlier you catch an issue the better - so if your unit tests pass, but your integration tests fail - or if you only encounter an issue in human testing - the priority should be to make sure that issue is flagged *as soon as possible*. In almost all cases you should be able to flag that in a unit test, or at the least in an integration test.

wait, you guys test?

I'm the sole dev at my small hosting company. I do unit testing, but nothing after that. I have to rely on stakeholders to accept that there is no QA team, and they should report issues to me directly.

Testing? What’s that? 🤔

In all seriousness though, I... don’t write tests because idk how to (right now) 😭

Exactly what @rutee07 said with the addition of integration and e2e tests.

@OmerFlame once you will work for a company or contribute code to a seriouse repository you will be forced to 😅

Testing is the guarantee you are not refixing bugs or introducing new bugs while fixing other bugs or when creating new features which also require you to write new tests.

Ideally there shouldnt be a function without a unit test, integration/system tests between functions or e2e tests for the whole system

@bioDan oh god oh fuck