I've been writing software for years, though always for myself. Part of that is because I do not test aside from just using it. Well, I know how to write tests on a technical level. But right now I have no idea how to actually use tests to write robust code and I question what use they provide above my current approach.
some questions
What is the workflow? Do I first write tests and then code that meets the tests?
How do I test my tests?
How do I know how much my tests cover?
When do I know I should write more tests?
At what point is testing not worth it due to the extra work not yielding enough value?
Why is most software so buggy despite the existence of tests?
How do I test user interfaces?
Should I test speed?
(how) are tests useful?
I have the lingering belief that the tests were invented by someone who had never heard of Goodhart's law and ever since, tests provide a false sense of code quality. But, I know of projects that do not have 10+ revisions after their initial version, which mine do tend to have so there's probably something for me to learn here.
(how much) should I use formal verification?
Most importantly, I get the idea that the ideal test suite provides mathematical proofs about the existence of features that the tested function(ality) provides. But in practice I feel like my tests just end up being a copies of the implementations they test, which does not seem right (or useful).
Is the benefit of formally verifying my functions worth cost? Is the cost that much higher than mere unit tests? If you can instill in me a mindset that makes me write formal verifications at a pace proportional to unit tests, I'm most likely to award you mana.
answers that just recommend certain resources are good
I will award you ~5-50 mana if you provide answers that I couldn't (easily) find by just asking GPT or Google. Answers can just be links to recommended books, (or videos, though I'd rather read / practice) preferably free ones. Answers can also be manually written explanations, if you think that adds value above me just reading the right resources (probably this only/mostly adds value when you summarize big things I might only merely skim, or if you tight together different theories). I'll be grumpy if I notice you just let GPT do the talking.
software-agnostic answers
I mainly use Python for ML and Rust for front-end and have written hello_worlds for most popular languages. You don't need to focus on any specific programming language unless you think that's useful.
1,000People are also trading
1) Workflow: Generally, I am a fan of thinking about the code for a bit, writing tests, writing the code, and then potentially adding more tests. This enables being better aware of the edge/hard cases when writing the tests, while also not constraining your tests to a specific implementation (to ensure they don’t have the same blind spots as the code).
2) You can think of it as the tests and the code testing each other. If a test fails, you will automatically consider whether the test itself is buggy when you begin debugging. Generally, tests should be hardcoded as much as possible (minimize complexity in the test), or follow a structure where later tests only use results that are confirmed to be computed correctly from earlier tests.
3) There are tools out there that can automatically check whether your tests cover every possible branch. Other than that, it’s just about thinking hard enough about the problem and making sure you have examples of all the hard cases.
4) Really depends on the complexity of the program.
5) You aren’t just writing tests for the current version of your code. These tests are most useful when someone (possibly you) modifies the code in the future. It’s much easier to break code from the past that you don’t fully understand, and having robust tests is really useful at that time.
6) code is complicated and testing well is hard
7) no idea tbh I’m not experienced with this
8) possibly, it really just depends on the application
In general, to test your Python code, you should use pytest! It's open-source, available for anyone via the Python Package Index, and the syntax is relatively simple (in short: every function whose name begins with test is treated as a test case).
I've been writing software for years, though always for myself.
This is the reason. The usual software engineering advice, testing included, is written from the perspective of someone who works in a 100+ developer team on a 100k+ line project for 1MM+ users. If you're not at that scale, a lot of this stuff doesn't actually matter.