Timeline for Should you test configuration?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 24, 2024 at 11:14 | comment | added | Ewan | I agree "You don't test data" is just common sense, all the noise is just people arguing about the definition of "configuration", which i think we can all agree in common usage means "configuration data" | |
| Sep 23, 2024 at 7:46 | comment | added | freakish | Because if you have a static analysis tool then it also has its own configuration. Would you test that as well? Of course not. | |
| Sep 23, 2024 at 7:39 | comment | added | freakish | Btw, you don't test C/C++/C#/Java source code. Noone does. You test behaviour, maybe performance, regardless of how it is written after compilation/interpretation. Well, some people do test code, e.g. for static analysis and coding conventions. But then the code becomes your product, so it's the same thing, from different perspective. | |
| Sep 23, 2024 at 7:31 | comment | added | freakish | @BartvanIngenSchenau that's a side effect of every test. You not only test your own business logic but also that compiler produces correct code. I don't see a problem. And yes, just because you have a tool, it doesn't mean you should trust it. Or yourself (e.g. that this XSLT input generates expected output). That's what tests are for. | |
| Sep 23, 2024 at 7:24 | comment | added | Bart van Ingen Schenau | @freakish, XSLT is a language (in XML) for transforming XML documents. There are tools that can process XSLT, but stating that you won't test XSLT because you can test those tools is equivalent to stating you won't test C/C++/C#/Java code because you can test the respective compilers. | |
| Sep 23, 2024 at 6:53 | comment | added | freakish | @greenoldman am I disallowing anyone do anything? Do what you want, that's not my business. As for JSON testing, I have no idea what you even mean by that, and how can you test JSON outside of its usage. Plus as I already said: you can test JSON parsing and validation. That's the real thing you test, not JSON. Have you even read my answer? | |
| Sep 23, 2024 at 5:40 | comment | added | greenoldman | Well, if you don't test JSON that's fine, but allow other tests this. I'd better write completely basic JSON test and catch problems early instead of writing bigger test just to find out problem caused by some JSON. | |
| Sep 23, 2024 at 4:17 | comment | added | freakish | @user1937198 I don't know what XSLT is, or how it works. But if it is some kind of template engine than surely there is some tool associated with it. Then yes, you have input, and output. So you can test that tool. Standalone XML is meaningless, and not testable. That's the whole point of my answer. I thought I'm quite clear on that. | |
| Sep 23, 2024 at 1:10 | comment | added | user1937198 | You say don't test XML? Would you test XSLT? I've seen web api scraping parsers with all of their logic in XSLT. Would you not test them? | |
| Sep 22, 2024 at 20:38 | comment | added | Greg Burghardt | I'm very conflicted about this answer. The first paragraph is flat out wrong... except I'm not sure how you are defining "test." If you meant "unit test" then I would say most likely you are correct. However you do need to test that things are configured appropriately for a particular environment, but that doesn't mean "unit test." Honestly, your answer should start with the quote from the OP, because you are bang on from that point onwards. What the OP is describing is not configuration. | |
| Sep 22, 2024 at 9:16 | history | edited | freakish | CC BY-SA 4.0 |
added 70 characters in body
|
| Sep 22, 2024 at 7:54 | history | edited | freakish | CC BY-SA 4.0 |
deleted 38 characters in body
|
| Sep 22, 2024 at 7:23 | history | edited | freakish | CC BY-SA 4.0 |
added 289 characters in body
|
| Sep 22, 2024 at 6:38 | history | answered | freakish | CC BY-SA 4.0 |