|
Not all automated tests have significant value over manual validation.
|
#
?
Oct 24, 2022 15:55
|
|
|
|
| # ? May 27, 2024 14:39 |
|
|
Rocko Bonaparte posted:A lot of problems with all of methodologies is that you'll get them to work with reasonably experienced and motivated people that aren't bound to it as a metric but it'll fail for unmotivated or inexperienced people--or it'll fail if it's made a metric in some way. And strangely, reasonably experienced and motivated people tend to do well without them as well!
|
|
#
?
Oct 24, 2022 17:52
|
|
|
I'm not a TDD™ advocate, but I do find in my own personal dev workflow I find it very effective to write unit tests as I go when facing something like "need a new class/method that does X". I can iterate much faster by throwing together a few unit tests that run in seconds instead of rebooting my app/service, making API calls or UI clicks, inspecting behavior, etc. It gives me much greater speed and confidence in the code as I write it. That seems like the essence of what TDD is trying to get at but without the religion and zealotry around it. And obviously that approach works best when what I need to implement is relatively clear cut, which is absolutely not always the case. Sometimes I'm just in gently caress around and find out mode while working through ambiguity, in which case writing a bunch of tests is a hindrance and velocity killer, IMO. Once the approach is more formalized then come back and write some tests.
|
|
#
?
Oct 24, 2022 18:45
|
|
|
I've heard a few people talk about exploratory programming vs. actual building and I think we should all think a little bit more about that distinction. The tool sets and work flows that are appropriate for those activities are pretty different and if we had the vocab to talk about them it might help to clarify some good ideas and practices.
|
|
#
?
Oct 24, 2022 18:47
|
|
|
ultrafilter posted:I've heard a few people talk about exploratory programming vs. actual building and I think we should all think a little bit more about that distinction. The tool sets and work flows that are appropriate for those activities are pretty different and if we had the vocab to talk about them it might help to clarify some good ideas and practices. I think this is a good sentiment. I don't even know if I've heard it called exploratory programming before, but it's so appropriate to what my style of development favors. Exploratory POC, refactor, build & test extraction, deliver. But has anyone just tried not writing bugs in their code? It works really well if you just don't write bugs or bad code. [/s]
|
|
#
?
Oct 24, 2022 19:02
|
|
|
ultrafilter posted:I've heard a few people talk about exploratory programming vs. actual building and I think we should all think a little bit more about that distinction. The tool sets and work flows that are appropriate for those activities are pretty different and if we had the vocab to talk about them it might help to clarify some good ideas and practices. I struggle with this distinction when we ship the exploratory bits because "close enough" or "we just wanna run a small experiment". Still valuable to think about, but I find it hard to put into practice unless I keep it a secret.
|
|
#
?
Oct 24, 2022 19:08
|
|
|
I've been working on the hypothesis that tests should be simpler than the code they're testing, which ends up ruling out most unit tests, and I'm ok with that. If your unit of code is algorithmically dense, then yeah, write some unit tests for it. But most of them aren't, and testing their "API" seems to add more brittleness than robustness. Tests, by definition, make your application harder to change. The upside is that they make it harder to change accidentally, but the downside is that they make it harder to change on purpose. I feel like relatively little of the commentary I've read on testing discusses them with that tradeoff in mind.
|
|
#
?
Oct 24, 2022 19:45
|
|
|
ultrafilter posted:I've heard a few people talk about exploratory programming vs. actual building and I think we should all think a little bit more about that distinction. The tool sets and work flows that are appropriate for those activities are pretty different and if we had the vocab to talk about them it might help to clarify some good ideas and practices. I think about Wardley Maps a lot. Simon Wardley separates different roles and activities as (metaphorically) Pioneers, Settlers, and Town Planners. Each role handles different problems, has different inputs and outputs, and build on each other. Because of all this, they each require different tools and processes. TDD and Scrum are great tools that aren’t appropriate for every role.
|
|
#
?
Oct 24, 2022 21:37
|
|
|
Good tests make your application much easier to change on purpose. In a large, mature code base, typing the code to add the desired new functionality is a very small portion of the time taken to make a change. If you're changing a button from blue to green and that makes a test fail, then sure, it's slowed you down. For anything that's not completely trivial where you need to first understand what the current code is doing and why, tests are very valuable for that step.
|
|
#
?
Oct 24, 2022 21:43
|
|
|
raminasi posted:Tests, by definition, make your application harder to change. The upside is that they make it harder to change accidentally, but the downside is that they make it harder to change on purpose. I feel like relatively little of the commentary I've read on testing discusses them with that tradeoff in mind. This is probably the case on many teams, but I wouldn't agree that it's a foregone conclusion. This is why my effort post a ways back included mention of design by guarantee. If you lean on guarantees from your stack/patterns: you don't need to write code for caching if your OS does it. You don't need to write code for handling empty lists if you have a NonEmptyList type. And if you don't need to write the code, you don't need to write tests. The tests you do have to write are for important things. Maybe tests making your app harder to change is a smell that should be explored? tl;dr: barkbell posted:the less code you write the fewer tests you need
|
|
#
?
Oct 24, 2022 21:44
|
|
|
luchadornado posted:you don't need to write code for caching if your OS does it. It's not what you're saying but this is reminding me of the paper "Are You Sure You Want to Use MMAP in Your Database Management System?"
|
|
#
?
Oct 24, 2022 21:51
|
|
|
Plorkyeran posted:Good tests make your application much easier to change on purpose. In a large, mature code base, typing the code to add the desired new functionality is a very small portion of the time taken to make a change. If you're changing a button from blue to green and that makes a test fail, then sure, it's slowed you down. For anything that's not completely trivial where you need to first understand what the current code is doing and why, tests are very valuable for that step. luchadornado posted:Maybe tests making your app harder to change is a smell that should be explored? By "harder to change," I mean, like, mathematically: "builds that compile [or syntactically validate or whatever] and pass the test suite" are a subset of "builds that compile." That's true regardless of the quality of the test suite or how the application itself is factored. A well-designed test suite will make it easier to change the application correctly by making it harder to change the application incorrectly, by being calibrated to block all and only unintended changes (in the limit). But my point is that miscalibration of the suite can impede intended changes as well and bog things down, and this is what I feel gets left out of testing literature that assumes that more tests are always better.
|
|
#
?
Oct 24, 2022 23:03
|
|
|
pokeyman posted:It's not what you're saying but this is reminding me of the paper "Are You Sure You Want to Use MMAP in Your Database Management System?" Thanks, I hadn't read that before and it was an interesting read. raminasi posted:But my point is that miscalibration of the suite can impede intended changes as well and bog things down, and this is what I feel gets left out of testing literature that assumes that more tests are always better. That makes sense. Tests should help you move faster with more confidence, but a lot of tests on a dumpster fire just means you have a well-tested dumpster fire.
|
|
#
?
Oct 25, 2022 00:16
|
|
|
Never not just shipped the "exploratory programming". If it works and provides value nobody is going to want to wait for, or pay me, to write it twice.
|
|
#
?
Oct 25, 2022 02:56
|
|
|
Yeah, I've never seen anyone go "Ah, that was a great proof-of-concept and we learned a lot. Now time to chuck it and start again on the real program!" Ofc the POC is just going to evolve into the final program. That's why exploratory program should be somewhat structured; to avoid architectural dead ends and needless refactors. TDD can help as scaffolding to coerce you to consider your inputs / outputs / data structures, and to build testable code... but like real scaffolding, you take it down when the building is strong enough to support itself. You probably don't need the entire corpus of tests you developed as you were still exploring how to build your program; you just need a key few.
|
|
#
?
Oct 25, 2022 05:27
|
|
|
minato posted:Yeah, I've never seen anyone go "Ah, that was a great proof-of-concept and we learned a lot. Now time to chuck it and start again on the real program!" Ofc the POC is just going to evolve into the final program. Thanks, glad to know I wasn't just lol'ing into a vacuum
|
|
#
?
Oct 25, 2022 06:10
|
|
|
minato posted:Yeah, I've never seen anyone go "Ah, that was a great proof-of-concept and we learned a lot. Now time to chuck it and start again on the real program!" Ofc the POC is just going to evolve into the final program. every line of code I write is a precious baby which deserves nutrients to thrive
|
|
#
?
Oct 25, 2022 06:18
|
|
|
Sivart13 posted:every line of code I write is a precious baby which deserves nutrients to thrive i seek to destroy every line of code i've ever written, like a crazed arachnid mother eating its young before they may ever see light the day the only good code is code that was never written
|
|
#
?
Oct 25, 2022 06:38
|
|
|
thotsky posted:Never not just shipped the "exploratory programming". If it works and provides value nobody is going to want to wait for, or pay me, to write it twice. I've only seen it not shipped if it's built as an incomplete and independent mock of something that's novel for the team/org in some way. Eg I've seen people throw a Minecraft server into docker before containerizing services anyone cares about. Or built up demos going over something from a talk or blog post to evaluate whether they seem useful. The scope of this stuff is usually hours or a couple days as an evaluation of something at the core of system architecture. I've never seen an implemented feature get thrown out and rewritten because someone said they wanted to do it right instead. At least not unless "do it right" is a proxy for "the <important_title> wanted to try doing it too". When I have seen that, it's been a crapshoot on whether the "good" version is any better than the prototype.
|
|
#
?
Oct 25, 2022 06:57
|
|
|
Steve French posted:And strangely, reasonably experienced and motivated people tend to do well without them as well! Maybe but I haven't seen it happen yet. What I usually get from that from somebody that seems to otherwise know what they're doing is something that works on their machine with their specific circumstances, and they've kind of conditioned themselves to it like a Skinner Box, so anybody else even looking at it causes it to fall right over.
|
|
#
?
Oct 25, 2022 16:29
|
|
|
Xarn posted:How does that even work? I don't think I ever worked at any place where the management had any idea of what the PR gate status is. Sure, they know whether it is merged or not, there are blockers or not, but whether it is merged was never up to them. Dev D tells his boss he put a PR up. Reviewer R tells D to make changes. D tells his boss he's going to miss the deadline because R asked him to make changes. D's boss tells R to approve the PR (or D's boss tells his boss and his boss tell's R's boss who tells R). R tells management no - PR does not meet company standards or industry best practices. Management asks around until they find a reviewer who is willing to approve the PR without the changes. D's broken PR gets merged in. Everything goes to poo poo sooner or later - usually the first time someone tries to use the new feature. I'm not saying this is a good way to run things. I'm specifically saying it's a bad way to do things. I spent several years as a contractor. Not a single contract I took during that time was from a company that was not in serious trouble. The worst company I ever worked at full time was still a big step up from the best company I worked at as a contractor. All of my experience indicates that good companies don't hire contractors because if you've got a viable workflow, you don't need them. On the upside, I now know what not to do. Rocko Bonaparte posted:The people submitting the PR that is getting rejected complain to the reviewer's manager that the reviewer is gating them. Exactly thotsky posted:Never not just shipped the "exploratory programming". If it works and provides value nobody is going to want to wait for, or pay me, to write it twice. The only time I've gotten away with throwing away exploratory code is if I didn't tell anyone that's what I was doing. So now I'll instead say something like "Testing revealed an unexpected issue so I'm reworking the solution to resolve it" or "I'm currently tracing the code paths to 'find all impacted modules'/'figure out where to make the change'"
|
|
#
?
Oct 25, 2022 17:38
|
|
|
raminasi posted:By "harder to change," I mean, like, mathematically: "builds that compile [or syntactically validate or whatever] and pass the test suite" are a subset of "builds that compile." That's true regardless of the quality of the test suite or how the application itself is factored. You're allowed to just delete tests which are no longer applicable. If you find that pre-existing tests are bogging you down, that is a sign that you're approaching testing incorrectly and not an inherent part of having tests. It may mean that your fundamental approach to testing is a bad one (e.g. if you're trying to test a GUI via brittle UI automation that makes every minor change break everything), or that your tests are simply poorly designed, or just that you're failing to treat your test code as code which needs to be refactored and deleted whenever possible.
|
|
#
?
Oct 25, 2022 19:35
|
|
|
LLSix posted:... Do you have any team members that could learn from this code?
|
|
#
?
Oct 26, 2022 04:20
|
|
|
downout posted:Do you have any team members that could learn from this code? I didn't write the original bit but have done some prototyping; I haven't had to lie about as much as the OP though. Generally, the original prototype is useful for demonstrating the features but for understanding how to accomplish from code, it's complete poo poo. Other developers are better off seeing the core, important parts polished and isolated. I should be trying to have them profit from my misfortune. If there are specific lessons from the exploration, they should come out in a little report. Most of that isn't really specific to the code and more about whatever we're trying to do, and that institutional knowledge is gold. Even while prototyping, I'm deleting poo poo all the time already, and nobody--including myself--has ever gone far back in the revision history for a prototype to particularly see the trials and tribulations of previous attempts. At best, somebody would go back to trace a regression.
|
|
#
?
Oct 26, 2022 07:53
|
|
|
Career advice question. Not sure whether I should post here, but I guess I'm not a newbie anymore? After graduating from college I got hired by Amazon. I quit this year after working there for about 6 years, and now I feel rather lost career-wise. The work I did was pretty limited, designing and building in-house systems that trained/hosted ML models with AWS and Java and not much else, and the team I was in was a small one that was managed so badly that most of my time was spent trying to fix technical debt that was constantly increasing by new projects. We had absolutely no integration testing for years. In fact soon after I quit the team stopped existing and all the systems I worked on for the past 6 years were handed to some other team lol. If I hadn't quit by then I would have at that point. So now I look around and have no idea what to do. Presumably I can go get another Big Company job but I don't think I can pass a technical interview without studying for it for a while and I really don't have the motivation to do that only to get a job similar to the one I quit. I want to do something I give a drat about, and do it with some sense of freedom. I have to be near my sick mother so it has to be almost entirely remote as well. Money is not really a priority for me compared to quality of life and a sense of purpose at this point. I feel like I have a massive lack of overall technical knowledge, to the point I question considering myself a dev sometimes. I was overly specialized in the very specific things I did at work, but in the wilderness of unemployment I realize what I know doesn't really translate to anything I can do on my own. I look at projects that go "yeah I built this using rear end, Fart, Gloop and Shart" and I have no idea wtf is going on, or how someone even gets to learn this stuff. There's this weird isolation. Since I don't know anything I can't really be a part of a community that builds something, but in order to join said community I need to have a prerequisite level of experience I don't really have and don't know how to really obtain.
|
|
#
?
Oct 26, 2022 11:01
|
|
|
Plorkyeran posted:You're allowed to just delete tests which are no longer applicable. If you find that pre-existing tests are bogging you down, that is a sign that…you're failing to treat your test code as code which needs to be refactored and deleted whenever possible. Yes, and this is work. You’re describing the additional engineering work that needs to be done to modify the system under test, which is what I’m talking about. Even if you have stellar, well-factored tests, the work is required and has a cost, and that cost should always be balanced against the benefit the tests being.
|
|
#
?
Oct 26, 2022 11:59
|
|
|
Jabor posted:An excessive focus on unit tests can also often end up with you having a whole bunch of "change detector" tests that break whenever you make an intentional change to the code being tested, causing extra busywork for everyone working on it, while providing no ability to detect actual unintended regressions. you have very accurately described my unit tests lmao
|
|
#
?
Oct 26, 2022 14:24
|
|
|
UnfurledSails posted:Career advice question. Not sure whether I should post here, but I guess I'm not a newbie anymore? Sounds like job #1 is to figure out what you want to do. If you do think you want to stay in engineering, try doing and reading about other projects until you find something you like. Or maybe it wasn't the work you didn't like at the old place, but the poor team management. One you figure out what direction you want to go, you can start reading and doing your own projects to try that stuff out. There's really a ton of stuff out there for software development, but it takes your own time and motivation. Finding a new job won't be trivial. Places are hiring less right now, and its not uncommon for folks to need to study for these interviews. I went through a similar thing many years ago. I ended up joining some tech communities for learning and for just coding for charity. Spent some time volunteering at non-tech places too, just to not get lost in my head. That worked well for me.
|
|
#
?
Oct 26, 2022 14:36
|
|
|
Found it as I was googling on the side. https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContravariance.html This was one of those things that, when I say it I'm a weirdo who speaks martian, but when that famous misogynist says it, it's scripture. gently caress this industry.
|
|
#
?
Oct 26, 2022 14:45
|
|
|
Rocko Bonaparte posted:I didn't write the original bit but have done some prototyping; I haven't had to lie about as much as the OP though. Generally, the original prototype is useful for demonstrating the features but for understanding how to accomplish from code, it's complete poo poo. Other developers are better off seeing the core, important parts polished and isolated. I should be trying to have them profit from my misfortune. We do some stuff like this, but it's generally in the form of more various utilities. We still put them in source control, but don't have as rigorous code review, etc. It sounded a lot like what you were describing since they are usually one-off bits of code.
|
|
#
?
Oct 26, 2022 14:58
|
|
|
gbut posted:
This F# for Fun and Profit piece dunks on Uncle Bob, it's pretty fun. This is the snarkiest part: quote:You are practicing test-driven-development, enterprise-style, which means that you write a test, and then the Enterprise Developer From Hell implements code that passes the test. Unfortunately for you, the EDFH loves to practice malicious compliance, as we will see.
|
|
#
?
Oct 26, 2022 15:24
|
|
|
Then the tester implements a suite of spec tests and all the code that that rear end in a top hat wrote fails spectacularly and he gets fired. The end. e: missed the property test section in the F# article. lol gbut fucked around with this message at 15:59 on Oct 26, 2022 |
|
#
?
Oct 26, 2022 15:56
|
|
|
Jabor posted:An excessive focus on unit tests can also often end up with you having a whole bunch of "change detector" tests that break whenever you make an intentional change to the code being tested, causing extra busywork for everyone working on it, while providing no ability to detect actual unintended regressions. I have a solution for this
|
|
#
?
Oct 26, 2022 16:40
|
|
|
Rocko Bonaparte posted:I didn't write the original bit but have done some prototyping; I haven't had to lie about as much as the OP though. Generally, the original prototype is useful for demonstrating the features but for understanding how to accomplish from code, it's complete poo poo. Other developers are better off seeing the core, important parts polished and isolated. I should be trying to have them profit from my misfortune. Agreed. You said it better than I would have.
|
|
#
?
Oct 26, 2022 17:01
|
|
|
raminasi posted:This F# for Fun and Profit piece dunks on Uncle Bob, it's pretty fun. This is the snarkiest part: Thank you! I read this article a couple years ago and it made a big impression on me, been trying to find it again ever since.
|
|
#
?
Oct 26, 2022 17:24
|
|
|
Edly posted:Thank you! I read this article a couple years ago and it made a big impression on me, been trying to find it again ever since. read the goon book https://www.amazon.com/Property-Based-Testing-PropEr-Erlang-Elixir/dp/1680506218
|
|
#
?
Oct 26, 2022 18:11
|
|
|
bob dobbs is dead posted:read the goon book Purchased!
|
|
#
?
Oct 26, 2022 18:24
|
|
|
Rocko Bonaparte posted:Maybe but I haven't seen it happen yet. What I usually get from that from somebody that seems to otherwise know what they're doing is something that works on their machine with their specific circumstances, and they've kind of conditioned themselves to it like a Skinner Box, so anybody else even looking at it causes it to fall right over. This is a puzzling response to me; to clarify, I meant that reasonably experienced and motivated people tend to do well without developing as an adherent to some particular methodology(ies), though your response reads perhaps like you thought I meant they do well without tests? I've worked with plenty of folks who are experienced and motivated and write and maintain very solid code that is well designed, written, and tested, but that did not specifically follow TDD or some other methodology flavor. If your experience is that you only see good output like that when some such methodology is used, well, that sucks.
|
|
#
?
Oct 26, 2022 19:21
|
|
|
Okay I can buy into that. I've just seen too much stuff where people try to saying "developer-forward instead of process-forward" when all they wanted to do was cowboy like crazy. So instincts took over.
|
|
#
?
Oct 26, 2022 19:44
|
|
|
|
| # ? May 27, 2024 14:39 |
|
|
Man, I'm so done working with cowboys. My place has many, they "get poo poo done", and then the rest of us have to fix it for months and years afterwards. ne: of course they don't write any tests, why do you ask?
|
|
#
?
Oct 26, 2022 23:50
|
|