For developers under pressure, it’s better for bugs to be found in production
1–10 of 81 posts
Re: For developers under pressure, it’s better for bugs to be found in production
#2Tests that test services that do interesting thing in my code. I find that I can get 90% of my work done without ever firing up a web browser. It's cool to know that by the time you hit up the ui the code already works perfectly and I spent less time coding than otherwise.
So idk what this article is pointing out. Tests for test sake is probably that, but a big chunk of unit testing is definitely not bad for developers.
Re: For developers under pressure, it’s better for bugs to be found in production
#3Hahaha, I have been penalized for going steady enough times that I reached a point where I have no incentive to make services any better. I found it better to sweep issues under the rug and switch teams before it blows up.
It pains me but I am not going to care about it if I am going to be penalized for it.
Re: For developers under pressure, it’s better for bugs to be found in production
#4Re: For developers under pressure, it’s better for bugs to be found in production
#5> Tests can only tell developers they made a mistake. There is no gain at that moment.
The value is locating the problem code faster, and that generally can't be done efficiently in production. Outside a testing environment, you rely on logs alone to debug, or if you're more proactive you might grab session data but that means potentially sensitive user data is being cached and passed around to the support/triage team. At a security minded organization this should be impossible or at least difficult.
I agree it's not worth chasing Test Driven Development until you're actually testing during development.
This is a real problem, and it falls squarely on management. Testing needs time and resources, it needs priority and planning.
That's the reason I started speaking at conferences, started an online testing training course specifically for software managers, and am currently writing a book on the subject.
Re: For developers under pressure, it’s better for bugs to be found in production
#6I'm all for testing but honestly unit tests are the least valuable type of tests out there, I'd rather have an integration test that uses no mocks
Re: For developers under pressure, it’s better for bugs to be found in production
#7Re: For developers under pressure, it’s better for bugs to be found in production
#8Developer's dont write tests if writing tests is hard. Simple as that. If writing tests is hard because you never invested in setting up a good test infrastructure with helpful utilities, you fucked up. If writing tests is hard because your architecture is a cluster fuck of mixed responsibilities, you fucked up.
Re: For developers under pressure, it’s better for bugs to be found in production
#9Sprint "commitments" in my world. A single word with major psychological impacts.
Re: For developers under pressure, it’s better for bugs to be found in production
#10I'm all for testing but honestly unit tests are the least valuable type of tests out there, I'd rather have an integration test that uses no mocks
Most of the integration tests are for happy paths, i.e. ones where you can catch the obvious regressions. Testing corner cases is much more troublesome, because you have to set up a whole lot of specifics in multiple services. These are much easier to simulate with mocks.
Mind you, I hate unit tests for specific functions: I much prefer them as component tests, where you start with the inputs to the module and check the outputs and calls outside of the module. These ease refactoring where you actually change the underlying code and without changing the unit tests, you know that you also handled all those pesky corner cases.