5 ms·

The problem is, when devs don't write their own tests, the code they write tends to be untestable.

by robbyt 5y ago

onion2k 5y ago
I suspect you think the developer writes the code and then the QA engineer writes tests for that code. That's the wrong way round. The tests are written first, and they all fail, then the dev has to write code to make them pass. By definition it's literally impossible to write untestable code that way because then the tests won't pass. It's the principle of TDD but separated in to different roles. It works well and produces good results but you need exceptionally good planning upfront to actually do it.
- eliasbagley 5y ago
  Who designs the interfaces that the tests call?
  - onion2k 5y ago
    That's the planning part. Usually it's done as a collaboration between the systems architect and the QA team. The process is essentially "design the system architecture -> document the APIs -> write the tests -> implement the code -> QA". It takes a level of rigour and planning that most teams don't want to do, and it relegates developers to a pretty minor role in the whole development process. They end up just filling in the blank bits in someone else's design. Most changes in team structure over the past couple of decades have been about developers taking on more of the responsibilities rather than less. It's actually one of the aspects of TDD that makes it so robust. If you properly design your code and really think about its APIs you get a better app at the end. It does take longer to get something a user can see though, but often the process gets to a finished iteration of an app quicker because there's fewer cycles of debugging and fixing needed.
    - realusername 5y ago
      > The process is essentially "design the system architecture -> document the APIs -> write the tests -> implement the code -> QA". It takes a level of rigour and planning that most teams don't want to do That's a very charitable way to say it, on my case I would call this kind of process very convoluted and similar to early 2000s style development. I obviously would not want to work in such a bureaucratic environment where every small tech decision has to go through multiple boards.
      - onion2k 5y ago
        I obviously would not want to work in such a bureaucratic environment where every small tech decision has to go through multiple boards. Everyone who works on the app is making those decisions no matter what you do. The difference is that in the "old style" the decisions were made before the code is written, and in the agile "new style" the decisions are made after the code is written. Often that's fine, because developers are generally good at their work and they make decent decisions, but sometimes they get it wrong and that's when code design issues arise. It's also what leads to automated tests failing to test for a lot of cases that a good QA engineer would have written tests for. Those things have an impact on the user. A huge amount of the code in apps we use every day was never designed. No one thought it through. No one considered the edge cases. Features are thrown together in a week and 'sort of' work. Every time you see a shitty broken website, or a bug in production, or some crappy slow thing that should be fast the reason behind the problem is that the developers who made it didn't take the time (or even have the time in really bad companies) to think about what they were building. A lot of developers like that working environment because they can hack on things and move on to the next challenge quickly. That's fun. I argue it's also bad for users, and I care more about users than I care about developers (and I say that as a developer whose been making web stuff for almost 25 years.) I'm not arguing that we go back to Prince2 and waterfall. There's a limit to my tolerance of bureaucracy too. I'm saying that things have gone a bit too far the other way, and many developers need to spend more time planning what code is written before leaping in and coding up the first solution they think will pass the acceptance criteria someone from product wrote.
- zimpenfish 5y ago
  > The tests are written first That surely implies a specification which, in my experience, is a rare thing in these Agile days. > the QA engineer In the last 10 years of contract and perm jobs, only once have the QA people actually written tests (and that was largely translation of an existing manual suite to a node-based automatic runner.) It's pretty much always been "these are the things the devs/product manager/pm wants to test for these changes, please test those and approve".

The problem is, when devs don't write their own tests, the code they write tends to be untestable.

by robbyt 5y ago

The problem is, when devs don't write their own tests, the code they write tends to be untestable.

I suspect you think the developer writes the code and then the QA engineer writes tests for that code. That's the wrong way round. The tests are written first, and they all fail, then the dev has to write code to make them pass. By definition it's literally impossible to write untestable code that way because then the tests won't pass. It's the principle of TDD but separated in to different roles. It works well and produces good results but you need exceptionally good planning upfront to actually do it.

eliasbagley 5y ago
Who designs the interfaces that the tests call?
- onion2k 5y ago
  That's the planning part. Usually it's done as a collaboration between the systems architect and the QA team. The process is essentially "design the system architecture -> document the APIs -> write the tests -> implement the code -> QA". It takes a level of rigour and planning that most teams don't want to do, and it relegates developers to a pretty minor role in the whole development process. They end up just filling in the blank bits in someone else's design. Most changes in team structure over the past couple of decades have been about developers taking on more of the responsibilities rather than less. It's actually one of the aspects of TDD that makes it so robust. If you properly design your code and really think about its APIs you get a better app at the end. It does take longer to get something a user can see though, but often the process gets to a finished iteration of an app quicker because there's fewer cycles of debugging and fixing needed.
  - realusername 5y ago
    > The process is essentially "design the system architecture -> document the APIs -> write the tests -> implement the code -> QA". It takes a level of rigour and planning that most teams don't want to do That's a very charitable way to say it, on my case I would call this kind of process very convoluted and similar to early 2000s style development. I obviously would not want to work in such a bureaucratic environment where every small tech decision has to go through multiple boards.
    - onion2k 5y ago
      I obviously would not want to work in such a bureaucratic environment where every small tech decision has to go through multiple boards. Everyone who works on the app is making those decisions no matter what you do. The difference is that in the "old style" the decisions were made before the code is written, and in the agile "new style" the decisions are made after the code is written. Often that's fine, because developers are generally good at their work and they make decent decisions, but sometimes they get it wrong and that's when code design issues arise. It's also what leads to automated tests failing to test for a lot of cases that a good QA engineer would have written tests for. Those things have an impact on the user. A huge amount of the code in apps we use every day was never designed. No one thought it through. No one considered the edge cases. Features are thrown together in a week and 'sort of' work. Every time you see a shitty broken website, or a bug in production, or some crappy slow thing that should be fast the reason behind the problem is that the developers who made it didn't take the time (or even have the time in really bad companies) to think about what they were building. A lot of developers like that working environment because they can hack on things and move on to the next challenge quickly. That's fun. I argue it's also bad for users, and I care more about users than I care about developers (and I say that as a developer whose been making web stuff for almost 25 years.) I'm not arguing that we go back to Prince2 and waterfall. There's a limit to my tolerance of bureaucracy too. I'm saying that things have gone a bit too far the other way, and many developers need to spend more time planning what code is written before leaping in and coding up the first solution they think will pass the acceptance criteria someone from product wrote.
zimpenfish 5y ago
> The tests are written first That surely implies a specification which, in my experience, is a rare thing in these Agile days. > the QA engineer In the last 10 years of contract and perm jobs, only once have the QA people actually written tests (and that was largely translation of an existing manual suite to a node-based automatic runner.) It's pretty much always been "these are the things the devs/product manager/pm wants to test for these changes, please test those and approve".