Automatically generate test cases for Web, iOS and Android components, with Gherkin test scenarios
- Culture: mutual trust, willingness to learn and continuous improvement, constant flow of information, open-mindedness to changes and experimentation
- Automation: deployment pipelines (CI/CD), comprehensive test automation
- Lean: minimize WIP state, shorten and amplify feedback loops, look for opportunities to remove waste, fix errors as they are discovered
- Measurement: monitoring, system metrics, KPIs
- Sharing: sharing knowledge & practices, including successes & failures, learn from each other's experiences, proactively communicate, shadowing & pairing on tasks
The idea for SQLite actually came out of his frustrations with an existing database called Informix that was installed on a literal battleship
they said, “Well, do you have any pricing information?” “Well, look, I tell you what, let’s have a call tomorrow and I’ll get back to you on that.”
Of course, inside, I was like, “What? You can make money with open source software? How does this work? How do I price this? I have no idea how to do this.”
Somehow or another, and I don’t know how this happened, Mitchell Baker, she’s the woman who runs the Mozilla Foundation, she got wind of this and called me up, says, “Richard, you’re doing this all wrong. Let me tell you how to set up a consortium.” She laid down the law, says, “Look, the developers have to be in control. Their decision is final. No voting rights on what gets to go into it. The companies that are using, they get the honor of contributing money, but you make all the decisions.” She was very adamant about this and she laid out everything. She’s a lawyer.
I actually started following some of their processes, and one of the key things that they push is, they want 100% MCDC test coverage.
That’s modified condition decision coverage of the code. Your tests have to cause each branch operation in the resulting binary code to be taken and to fall through at least once.
I looked at Git, I looked at Mercurial, and I looked at my requirements and I thought, “You know what? I’m just going to write my own,” so I wrote my own version control system (fossil), which is now a project unto itself, and that worked out very, very well
Source : https://sebsauvage.net/links/
"Devs should be able to run entire env locally. Anything else is just a sign of bad tooling"
"pre-production testing is a best effort verification of a small subset of the guarantees of a system and often can prove to be grossly insufficient for long running systems with protean traffic patterns"
"The writing and running of tests is not a goal in and of itself — EVER. We do it to get some benefit for our team, or the business"
"there are coverage based fuzzers like afl as well as tools like the address sanitizer, thread sanitizer, memory sanitizer, undefined behavior sanitizer and the leak sanitizer to name a few."
"This was but one example of a system that didn’t stand much to benefit from integration testing and where monitoring has worked much better."
Urchin is a portable shell program that runs a directory of Unix-style programs and produces pretty output. It is normally used for testing shell programs, where each test case corresponds to a single file in the directory that Urchin runs.
"3) Service virtualisation:
- Wiremock (I used this one: very simple & efficient)
- VCR / Betamax
big-list-of-naughty-strings - The Big List of Naughty Strings is a list of strings which have a high probability of causing issues when used as user-input data.
shpec - Test your shell scripts!