Ask HN: What Are Your Most Important Software Testing Ideas and Practices? | Hacker News Reader

Ask HN: What Are Your Most Important Software Testing Ideas and Practices?

6 pointsvednig11 comments

We're exploring ways to improve software testing in modern development workflows and would love to learn from this community's experiences.

What are the key ideas, practices, or philosophies that have been game-changers for your testing process? This could be:

Automated testing tools or strategies Unique approaches to integration or unit testing How you handle edge cases, performance testing, or regression Ways to integrate testing into CI/CD pipelines effectively Lessons learned from testing failures

Looking forward to hearing about what has worked (or not!) for you. Let's spark some great ideas that can benefit everyone in the industry!

-- PS: If you have open-source tools or frameworks you swear by, please share!

View on HN

My experience based on web oriented technology with overcomplicated systems choices :

- End to end testing is good for critical path (customer can create an account ? Otherwise he will leave for another company = very bad). It cost a lot to maintain thus, must be very important requirement. Page pattern with selenium is good.

- Hight level Integration testing (real component, no mocking) is great : tons of error come from the integration of the many components/teams (BDD, ETL, external API/lib, [...]). When tested from your API end point, you have a great ROI and good security harness to avoid regression. By the past we used postman but there is better alternative now.

- unit testing : good when you have control of the solution. As software integration team, working on very legacy solutions, core logic doesn't belong to us. Unit test have not been helpful in our case when using mock (too much maintaining cost)

Can be used for other context than web

Today, we encountered a very critical bug that would be missed with unit testing and integration testing, which changed our whole approach towards how we view testing. It was a simple scrollbar not being able to scroll 90% times only worked 10% if a user did very specific thing. Overall chance of getting noticed in beta test would have been 2% but as a startup this could have been our end, because unless user added more than 5 files one could not test the scenario, which is the avg. for any trial user. But a real user would have noticed this and would have left for another company. When we started we hadn't hoped this would be an issue but here we are.

In my last few projects I've made it possible to record inputs and outputs of applications and persist the data to disk. I've written tests that use the recorded inputs and compare the results to the recorded outputs. This meant we could record tests rather than writing them. We also record the results of testing sessions with end users and convert the results into tests.

* investment (instead of dogma) driven approach to testing

* hermetic end to end tests - tests that test your code in a hermetically sealed environment using fakes.

* automatic generation of documentation from story driven tests

Do you know any library that allow quick injecting fakes in "hermetically sealed environments"? > automatic generation of documentation from story driven tests How is that possible?

Manual testing only for various cases. The development already costs testing.

Dont test implementation. Test as closer to the end user perspective as you possibly can.

Explain the "don't test implementation"

Don’t test how something is done, test what is done.

For example - most of the time component tests in react are terrible burden, not help.

The idea is that tests should not fail when implementation changes, but not the product.

Yes, that is something we're aiming for with a library that can emulate the user closest from end user perspective.

Reply on news.ycombinator.com