2 ms·

That sounds like an incredibly slow feedback cycle. How would that work? Write some code, check it in, wait for someone else to write tests... and come back in

That sounds like an incredibly slow feedback cycle. How would that work? Write some code, check it in, wait for someone else to write tests... and come back in hours/days/weeks to fix any issues? Getting constantly dragged back to fix last week's bugs sounds like a chapter from Dante's Inferno. I'd rather discover them while the code is fresh in my mind. Without tests, how do I know when I'm done?

quiescant_dodo 6y ago
In the past, I had pseudo-pair programmed in order to test. We'd agree on the external-facing API and pair-program a slow in-memory implementation. Once that was completed, we would split off and one of us would write test cases against the API (fixing up the in-memory implementation as needed) while the other would work on a proper database-backed implementation. I haven't done this in probably 7 years, though. Mostly because I haven't cultivated this kind of working relationship with my coworkers.
fossuser 6y ago
I've seen both types of org layouts where I've worked (we moved from one to the other). Initially separate QA teams that would write tests, a subset of which might do manual testing in the UI. The feedback loop for this was brutal as you suggest and caused a lot of problems, with delayed breaks that become hard to fix and debug. It's also hard for QA to often know what the code is doing or interact closely with the dev teams. You can try to get them to be as close as possible, but it doesn't work super well. Now devs are responsible for writing tests and teams think about potential failures when designing things/discussing the plan with their team. They were supposed to consider these things before too, but the incentives weren't aligned - now they are. We have infrastructure teams to make automated testing as easy as possible and spin up a test environment where you can see your change, etc. I think this model is better, testing well is hard and reasoning about failures and how things can go wrong is an important skill to develop. Offloading this to a different team feels like a variant of the dev that 'just writes features' and doesn't consider actual deployment. This is often made doubly worse by companies that have QA teams often treating them as second class citizens both in status and in pay. I think it's better to have it be part of the job of the person writing the feature also write the tests, it doesn't help that writing tests is something few people know how to do coming out of school.
01100011 6y ago
Write the spec. Write the tests. Write the code. I'm taking about API and system level tests. Unit tests vary in scope between 'test a function' and 'test a unit interface'. Former should be done by the dev during development. Latter should be done by someone else. It's a grey area between those extremes. I'm coming from a systems programming and embedded background so I have no idea if a web dev or someone else should follow my advice, but I suspect so.

quiescant_dodo 6y ago

In the past, I had pseudo-pair programmed in order to test. We'd agree on the external-facing API and pair-program a slow in-memory implementation. Once that was completed, we would split off and one of us would write test cases against the API (fixing up the in-memory implementation as needed) while the other would work on a proper database-backed implementation. I haven't done this in probably 7 years, though. Mostly because I haven't cultivated this kind of working relationship with my coworkers.

fossuser 6y ago

I've seen both types of org layouts where I've worked (we moved from one to the other). Initially separate QA teams that would write tests, a subset of which might do manual testing in the UI. The feedback loop for this was brutal as you suggest and caused a lot of problems, with delayed breaks that become hard to fix and debug. It's also hard for QA to often know what the code is doing or interact closely with the dev teams. You can try to get them to be as close as possible, but it doesn't work super well. Now devs are responsible for writing tests and teams think about potential failures when designing things/discussing the plan with their team. They were supposed to consider these things before too, but the incentives weren't aligned - now they are. We have infrastructure teams to make automated testing as easy as possible and spin up a test environment where you can see your change, etc. I think this model is better, testing well is hard and reasoning about failures and how things can go wrong is an important skill to develop. Offloading this to a different team feels like a variant of the dev that 'just writes features' and doesn't consider actual deployment. This is often made doubly worse by companies that have QA teams often treating them as second class citizens both in status and in pay. I think it's better to have it be part of the job of the person writing the feature also write the tests, it doesn't help that writing tests is something few people know how to do coming out of school.

01100011 6y ago

Write the spec. Write the tests. Write the code. I'm taking about API and system level tests. Unit tests vary in scope between 'test a function' and 'test a unit interface'. Former should be done by the dev during development. Latter should be done by someone else. It's a grey area between those extremes. I'm coming from a systems programming and embedded background so I have no idea if a web dev or someone else should follow my advice, but I suspect so.