Interesting, I thought I had to turn that on for Obsidian!
The first time I started installing flatpaks I ran into a bit of permission / device isolation trouble and ever since then, I use flatseal after installing an app to make sure it actually has access to things.
I „love” such sandboxing defaults. Apps like Docker Desktop also share the whole home by default [1], which is pretty interesting if a big selling point is to keep stuff separated. No idea why node_packages need to have access to my tax returns :). Of course you can change that, but I bet many users keeps the default paths intact.
Security/dependancy updates depend solely on the specific maintainers. The platform itself doesn't automatically fix the developer or maintainer lethargy in this regard.
If you’re, for example, writing a web application, and you have an endpoint which parses some data from the request and then responds with the result of that computation, why the hell would you test the fine-grained behaviour of your parser by emulating HTTP requests against your server?
Testing the parsing function in isolation is orders of magnitude cheaper.
Your example scenario avoided doing an end to end test for the data processing involving the parser instead opting for a unit test just for the parser.
We have developer sandboxes for this purpose so you don't have to guess the structure of the data you will receive from the actual server.
Also if all else was equal between multiple types of test, there wouldn't be need for comparison ala cheaper.
How do you know that? How do you know that I wouldn't write an integrated test which verifies that my parser is correctly integrated with my system?
The point is, there is typically more than one path through the logic of a parser. The cheapest way to test these paths is in isolation. If there are five paths you care about, you could write six integrated tests — one for each of the five paths you care about, and one to verify that your parser is correctly integrated with your system, or of course you could write five isolated tests (which are cheaper to write and cheaper to execute) and one integrated test.
So, five cheap tests and one more expensive test, or six more expensive tests.
> Also if all else was equal between multiple types of test, there wouldn't be need for comparison ala cheaper.
…What? I'm sorry, this is near enough unintelligible.
> How do you know that? How do you know that I wouldn't write an integrated test which verifies that my parser is correctly integrated with my system?
You already said so in your first argument:
Unit tests are cheaper and better(than integrated tests I presume).
Am simply following your behavior pattern here.
> The point is, there is typically more than one path through the logic of a parser. The cheapest way to test these paths is in isolation. If there are five paths you care about, you could write six integrated tests — one for each of the five paths you care about, and one to verify that your parser is correctly integrated with your system, or of course you could write five isolated tests (which are cheaper to write and cheaper to execute) and one integrated test.
This is nonsense. A standard parser takes one input and does processing of this data to give an expected output. An integration test checks the parser does this one objective correctly. You have boiled down the 5 unit tests that don't test for anything *real into 1 integrated test that objectively gives better test data.
*code is not real until it does some business logic!
> Also if all else was equal between multiple types of test, there wouldn't be need for comparison ala cheaper.
> …What? I'm sorry, this is near enough unintelligible.
Maybe try to froth less when reading my comments, your brain might have some capacity left to understand comparitive adjectives.
Integration tests are as old as unit tests, and both predate their names. When exactly were unit tests made redundant? I don't see the point of your quip without a trace of actual argument.
I feel like I don't write enough tests, and when I do they're usually integration tests, but some things - algorithms, complex but pure functions, data structures - absolutely deserve their unit tests that can't be reasonably replaced by integration/e2e tests.
Unit tests don't matter when you have other types of testing like functional or integration testing that will tell you whether your code has the intended behavior and effect when run.
In the above statement unit tests is also considered as code.
Unit tests do matter, especially when the logic is somewhat complex or very defined (splitting money, parsing some message). So unless the specs change, you rarely have to modify the tests. So it helps more in a technical sense, catching developer mistakes. Just like qa tests on some small part of the car can spot defect early on.
Integrated tests is more about ensuring what matters to Product. A car that refuses to start is worthless for most cases. But the engine light and a window that can’t open is not usually a dealbreaker.
Unit tests can help pinpoint an issue or ensure that a specs is implemented. But that’s mostly relevant to the developer world. So for a proper DX, add unit tests to help pinpoint bugs faster, especially with code that doesn’t change as much and where knowledge can be lost.
I find it funny that almost every talking point made about AI is done in future tense. Most of the time without any presentation of evidence supporting those predictions.
reply