|
leper khan posted:One of the problems with TDD is that neither of your benefits are necessarily realized to implement TDD. The tests can have negative value and the code doesn't need to be testable. These issues compound themselves.
|
#
?
Oct 22, 2022 17:25
|
|
|
|
| # ? May 27, 2024 18:22 |
|
|
awesomeolion posted:Things like ease of use (eg. for the caller of my code / api), ability for other engineers to tell what the code is doing, maintainability, ability to reuse my code is all important. Also important is getting other people that I work with to think that the code I write is well structured and architected. Because they're the ones giving feedback that I need to improve so I need to make them happy in a sense. I guess I could chase down more detailed feedback to try to figure out exactly what they saw that gave them a negative impression. This is a deep pool with a lot of potential things that could help, I can only offer what resonated with me: - Distilling Domain Driven Design down to the best parts. It's a big book and there's a lot of garbage out there, but if you just grab some things like event storming and minding your aggregates/domain boundaries and avoid the stuff that's low ROI, it can be a huge help - "Design by guarantee", leaning on any guarantees you can get from the hardware, OS, runtime, etc. This could be letting your db make better use of os page cache, leveraging causality from Kafka, or just using the type system to provide guarantees so that its impossible for your code to represent a state that isn't representable in your domain: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ - Grokking Simplicity. Even if you're not using Haskell or Clojure or something, separating your actions, calculations, and data in a functional way are huge. Once that feels good, expand the ideas to architecture (FCIS/Onion/Hexagon/whatever): https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell A lot of this all comes down to reducing accidental complexity in our software, and it's hard to do a better job of Rich Hickey when talking about it: https://www.youtube.com/watch?v=LKtk3HCgTa8&t=2s
|
|
#
?
Oct 22, 2022 17:32
|
|
|
awesomeolion posted:Anyone have tips for how to improve my architecture and design skills? I tend to jump in and try stuff rather than sitting back in my rocking chair and comparing every possible architectural option. So that's one issue I think. But when I sit there brainstorming architecture options it feels like it doesn't matter and I get sleepy. Have you tried reading up on Design Patterns? I'm mostly in a different world from most SW so I really can't follow a lot of the standard patterns, but I think it was helpful to get a different view and change my thinking.
|
|
#
?
Oct 22, 2022 17:44
|
|
|
TooMuchAbstraction posted:The value of TDD is twofold. First is the tests themselves, of course, which help catch regressions before they hit your clients. But second is that they force you to write testable code. If your code is a mess of long-lived threads and classes that reach deep into each others' pockets, then you have a lot of work to do before you can start writing useful tests. I agree with all of this. I've worked at... probably too many places because I spent half my career as a contractor. All the places I've worked that rely on and enforce unit tests passing have had smooth releases. All the places that don't use unit tests have had rough releases resulting in lots of overtime. At one company I was at briefly they had a policy of requiring unit tests to be written, but management also had a habit of okaying PRs with failing unit tests. Every single release where the unit tests passed were smooth. Every single release with a PR that failed unit tests had a rough release. In one particularly memorable release, an every-other-month release was delayed more than 3 months as a result of bugs caused by a change that commented out failing unit tests. I left for greener pastures shortly afterwards.
|
|
#
?
Oct 22, 2022 17:49
|
|
|
gbut posted:I've found that the whole idea of TDD does not really work in large orgs, especially if those orgs like to shuffle engineers around different teams every 6 months or so. It all ends up being a soup of low-hanging fruit that is also tightly coupled with implementation, mocks that don't implement the service interfaces well, and business-crucial stuff being skipped over because it's too hard to test due to complexity. I work in web space, so take this with a giant Himalayan salt rock. TDD was popularized from web space, and the big proponents seem to come from dynamically typed language backgrounds (e.g. ruby/php) etc. I think some of the core ideas are nice, but then you run into test suites that are mocks testing mocks while the service they're testing doesn't actually loving work and you wonder what's the point.
|
|
#
?
Oct 22, 2022 20:25
|
|
|
LLSix posted:At one company I was at briefly they had a policy of requiring unit tests to be written, but management also had a habit of okaying PRs with failing unit tests. 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.
|
|
#
?
Oct 22, 2022 21:16
|
|
|
Sivart13 posted:I like this article that puts a skeptical eye how TDD is hyped as a 'design technique'. Yeah, that mostly matches up with my own thoughts and experiences.
|
|
#
?
Oct 22, 2022 21:21
|
|
|
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. I work at a place where technically skilled VPs (real ones at a bigcorp) regularly intervene to solve technical problems. Seems like they do this because they don't know how to do their actual job so it makes a pleasant distraction.
|
|
#
?
Oct 22, 2022 21:23
|
|
|
waynes deffo generally a good read. ive been trying to get him to try and find some peeps who moved from computer-touching to trad-engineering in order to get the converse of his 'crossover project' where he looked at peeps who moved from trad-engineering to computer-touching to get peeps who complain about computer-touching not being engineering to shut up
|
|
#
?
Oct 22, 2022 21:28
|
|
|
The people submitting the PR that is getting rejected complain to the reviewer's manager that the reviewer is gating them.
|
|
#
?
Oct 22, 2022 21:31
|
|
|
bob dobbs is dead posted:waynes deffo generally a good read. ive been trying to get him to try and find some peeps who moved from computer-touching to trad-engineering in order to get the converse of his 'crossover project' where he looked at peeps who moved from trad-engineering to computer-touching to get peeps who complain about computer-touching not being engineering to shut up That just can't be a really big population though.
|
|
#
?
Oct 22, 2022 21:58
|
|
|
TDD is not the same thing as having [unit] tests. I don’t think anyone is arguing against having tests.
|
|
#
?
Oct 22, 2022 22:47
|
|
|
Tests are bad for job security, particularly the QA department
|
|
#
?
Oct 22, 2022 22:51
|
|
|
Focusing on unit tests such that you ignore top level tests is bad.
|
|
#
?
Oct 23, 2022 00:07
|
|
|
Steve French posted:TDD is not the same thing as having [unit] tests. I don’t think anyone is arguing against having tests. I would argue against having coverage-focused unit tests. Having some integration tests is nice, but it is possible to do that wrong as well.
|
|
#
?
Oct 23, 2022 00:22
|
|
|
ultrafilter posted:That just can't be a really big population though. he looked already for months for the original thing and found absolutely no-one
|
|
#
?
Oct 23, 2022 00:35
|
|
|
Coverage metrics are a really good way to identify the most poorly-written and hard-to-maintain parts of your codebase. At least, they are as long as no-one decides to make "improving test coverage" a goal in and of itself. At that point Goodhart's Law applies, and it loses its value as a metric.
|
|
#
?
Oct 23, 2022 00:47
|
|
|
StumblyWumbly posted:Focusing on unit tests such that you ignore top level tests is bad. What is a "top-level" test?
|
|
#
?
Oct 23, 2022 01:11
|
|
|
New Yorp New Yorp posted:What is a "top-level" test? Integration or End to End, depending on where you draw the line. My company added a lot of SW tests in pretty late, and the SW folks decided that the "pure" decision was to write complete tests for each function, starting with the ones that were easy to test for. The main SW was taking in some files and processing it in a variety of ways, and I think we could have gotten more utility more quickly if we had just run some known files with known outputs through, to make sure new features did not break the existing ones.
|
|
#
?
Oct 23, 2022 02:18
|
|
|
It's often the case that end-to-end tests are expensive to run or slow, while unit tests are cheap and fast. If your E2E tests are fast, then sure, just use those. You lose some specificity when a test fails, but odds are you can figure out what broke by looking at what the PR changed. My mantra generally is "code that is not tested does not work." It's not 100% true, but it comes within spitting distance.
|
|
#
?
Oct 23, 2022 02:43
|
|
|
TooMuchAbstraction posted:It's often the case that end-to-end tests are expensive to run or slow, while unit tests are cheap and fast. If your E2E tests are fast, then sure, just use those. You lose some specificity when a test fails, but odds are you can figure out what broke by looking at what the PR changed.
|
|
#
?
Oct 23, 2022 03:06
|
|
|
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.
|
|
#
?
Oct 23, 2022 04:09
|
|
|
I've often found that focusing on writing really (unit) testable code results in code that's harder to reason about initially because of all the dependency injection and tiny testable units you're creating. Sometimes the clearest way to do something is with procedural programming and the best way to test it is with an integration test.
|
|
#
?
Oct 23, 2022 05:45
|
|
|
TooMuchAbstraction posted:It's often the case that end-to-end tests are expensive to run or slow, while unit tests are cheap and fast. If your E2E tests are fast, then sure, just use those. You lose some specificity when a test fails, but odds are you can figure out what broke by looking at what the PR changed Brittleness is the real problem. Even the best-written E2E tests are going to be in a constant state of brokenness, and it just gets amplified the more of them you have. They're great as long as you have a limited number that verify that a few critical paths don't explicitly blow up. But validating actual application logic is best done at a deeper level. I'm in the "a single broken test is an immediate problem" camp, so the idea of having suites of brittle, flaky, slow E2E tests just makes me shudder. I've lived that before. No thanks.
|
|
#
?
Oct 23, 2022 08:39
|
|
|
New Yorp New Yorp posted:Even the best-written E2E tests are going to be in a constant state of brokenness, Uh, what? We have end-to-end tests that almost never get broken because about the only thing that breaks them is if the user flow that they're testing is actually not working - in which case your PR is broken and should not be merged!
|
|
#
?
Oct 23, 2022 10:32
|
|
|
Hot take: instead of writing unit tests for each method of each class in the entire project... just write unit tests from the entry point of your application and cover everything by passing in all of the use cases for your entry point. The only thing you should mock are your downstream calls. That way, it works just like an integration test but it's cheap and fast. Even if your component is 500K lines of code, that's why we have debuggers. If you really can't cover some code in this way then either you don't understand how your component works or that code can be safely removed. Maybe the only exception to this could be the middleware classes that intercept incoming and outgoing requests to the downstream components, because you're mocking their responses. fight me irl
|
|
#
?
Oct 23, 2022 13:59
|
|
|
Jabor posted:Uh, what? We have end-to-end tests that almost never get broken because about the only thing that breaks them is if the user flow that they're testing is actually not working - in which case your PR is broken and should not be merged! it depends on what you mean by "end-to-end" and how the tests are automated. qa managers can get real philosophical about how stuff is automated and demand that the automation ought to work just as a user would (which somehow means locating buttons in the user interface, clicking them, and pressing keyboard keys, as if the generation of messages sent to a window through mouse/keyboard events is a more "natural" way of testing than exposing an automation api) - this leads to extremely simplistic, brittle automation that is effectively a bunch of macros that break when your ui designers move buttons around as they are wont to do.
|
|
#
?
Oct 23, 2022 16:59
|
|
|
This gets especially obnoxious in a world where people think doing an A/B test between a button that says "Sign up now!" and "Sign up today!" is a worthwhile thing to do.
|
|
#
?
Oct 23, 2022 17:07
|
|
|
"but it improved the sign up by 1.7% [on that other page that's doesn't use that button]!"
|
|
#
?
Oct 23, 2022 17:15
|
|
|
Love Stole the Day posted:Hot take: instead of writing unit tests for each method of each class in the entire project... just write unit tests from the entry point of your application and cover everything by passing in all of the use cases for your entry point. The only thing you should mock are your downstream calls. First: tests from the entry point of your application are fundamentally not unit tests, so if we care about terminology then let’s not call them that. Comprehensively testing all important code in your application solely through the top level entry point would require an absolutely absurd quantity and complexity of tests for any moderately complex application/product.
|
|
#
?
Oct 23, 2022 18:33
|
|
|
Hadlock posted:Tests are bad for job security, particularly the QA department must be nice having a QA department
|
|
#
?
Oct 23, 2022 19:12
|
|
|
Capitalism is a race to the bottom, and you don't need quality there. I worked at only one place that had a QA team, and that team was dismantled shortly after I started. I never worked at a place that had a dedicated QA engineering team.
|
|
#
?
Oct 23, 2022 19:18
|
|
|
Happy to learn absolutely no progress has been made on testing since I got into the game 10 years ago.
|
|
#
?
Oct 23, 2022 20:15
|
|
|
thotsky posted:Happy to learn absolutely no progress has been made on testing since I got into the game 10 years ago.
|
|
#
?
Oct 24, 2022 01:30
|
|
|
the less code you write the fewer tests you need
|
|
#
?
Oct 24, 2022 01:34
|
|
|
gbut posted:"but it improved the sign up by 1.7% [on that other page that's doesn't use that button]!" And this of course is an improvement of 1.7% on the A page's 0.007% conversion rate so it's obviously statistically relevant!
|
|
#
?
Oct 24, 2022 05:44
|
|
|
qsvui posted:must be nice having a QA department Right up until there's any kind of financial distress, then they all get laid off
|
|
#
?
Oct 24, 2022 13:18
|
|
|
barkbell posted:the less code you write the fewer tests you need This goon gets it
|
|
#
?
Oct 24, 2022 14:40
|
|
|
Probably why TDD evangelists stop caring about tests when they move into management.
|
|
#
?
Oct 24, 2022 15:00
|
|
|
|
| # ? May 27, 2024 18:22 |
|
|
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. I have to deal with people in a hardware QA organization who write code and testing the code is not only alien but anathemic to them. These are people writing code to test things. You'd think somebody would have to come in and yell at them about trying too hard to test and cover everything, but instead all concepts for testing might as well be written in a moon language.
|
|
#
?
Oct 24, 2022 15:09
|
|