4 ms·

The design damage from TDD is very real, I'm unsure if the complexity added is of any real value. But once you turn your mind to it, it becomes second nature. I

by jbob2000 6y ago

The design damage from TDD is very real, I'm unsure if the complexity added is of any real value. But once you turn your mind to it, it becomes second nature. I wonder if people's woes about it are because it's hard to change? Regardless, TDD doesn't work for my org, it's too expensive. Our business logic is very unstructured, requirements are built up over years of projects being layered on top of each other. Decisions about business logic are made on a whim and need to implemented quickly to support the rest of the organization. Given how quickly and randomly the work changes, I'm not tempted to implement anything further than automated smoke tests. Besides, I have a QA team that is triple the size of my development team, it's their responsibility to test the end to end solution.

jrochkind1 6y ago
> Our business logic is very unstructured, requirements are built up over years of projects being layered on top of each other. That sounds to me like a codebase I'd be terrified to make changes in without extensive test coverage. (Whether the code was written with "TDD" or not is a slightly different question). But I guess it doesn't work out that way for you? Ah: > Besides, I have a QA team that is triple the size of my development team Sure, I guess that is an alternate approach to tests. I have never worked with a formal QA team that extensive, but I'd guess they have to have various scripts and explicitly written out acceptance criteria and such? That's basically a form of 'tests', just in human language and human testers, not code. (I also wonder if the QA team is actually using some forms of automation that look a lot like tests, just they write/maintain them instead of "developers"?) With a team three times the size of the dev team, it's definitely not a cheap alternative, but I guess I could believe it's cheaper/more effective than trying to have automated test coverage for your code (or a combo of much smaller QA team with some test coverage), like I could believe there is some context where that's true, it seems unlikely to me it will be widely true. But whatever works. The number of software development projects that lack either sophisticated QA operations like that or good test coverage is probably bigger than those doing either though.
- jbob2000 6y ago
  That's a good point - we're still doing TDD, just with "human code" instead of computer code. You're correct that they write out explicit test cases for each of the acceptance criteria. It's not cheaper than developers doing the testing, but it's more wholesome. They will test exactly how a user operates, with no regards for a software's boundaries. If part of the requirement is fulfilled by another team's software, they will test that other team's work. This works great for my team since we are highly integrated with the rest of the enterprise.
  - meheleventyone 6y ago
    The other amazing thing about proper QA testing that automated testing doesn't do so well is that they have the ability to go off script. Working in games the number of times I've built some feature or designed a level and thought I had tested it thoroughly only to have QA break it to pieces is very high! Your assumptions versus the assumptions of QA people and players are very different. A single, technically proficient QA expert on a team can be an incredible asset. Back that with a larger team to regression, smoke and otherwise test things and you'll not only find a load of bugs but also get early feedback on design. Automated testing definitely has a place. Libraries are a great example. There isn't really an end-user interface to test, it's not the conglomerate of much code and you basically need a test harness to even run your code. The downside is that you're typically back to only testing your own assumptions.
- sumtechguy 6y ago
  It is a fairly traditional way of doing it. TDD usually means you kinda know what is going on up front. If you work in a org where the sales guy can make up a feature and you need it done yesterday that can be a tough sell that you need time to write tests 'thats what we got QA for'. The refactor at this point is a daunting task. It would even be a decently expensive one. What comes out on the other end is effectively from the end users point of view, the same. I personally like working with a decent QA team. They challenge you to do better. They take a special glee in breaking your code in ways you did not think of. You can also use their test plans to write automated tests. So that way they can go think of more devious ways to break your code. Also sometimes developers can go off the deep end and over do things. It is nice to have a semi neutral third party saying what is important to test or not. Also one thing to keep in mind is many of these integration testing frameworks are basically tedious coding exercises. Especially if you are external API heavy. > it's definitely not a cheap alternative You may have hit on why many orgs like the idea of TDD. It pushes the idea that I have someone who can write code well they can write the tests too. Skipping over the fact that takes time and energy away from other things.
throw1234651234 6y ago
That's the only appeal of writing tests for non-critical functionality for me. If I know I have to write a test, I am likely to make a very clean method with a clear input / output. So it almost automatically follows SRP and is a pure function when I know it has to be tested.

jrochkind1 6y ago

> Our business logic is very unstructured, requirements are built up over years of projects being layered on top of each other. That sounds to me like a codebase I'd be terrified to make changes in without extensive test coverage. (Whether the code was written with "TDD" or not is a slightly different question). But I guess it doesn't work out that way for you? Ah: > Besides, I have a QA team that is triple the size of my development team Sure, I guess that is an alternate approach to tests. I have never worked with a formal QA team that extensive, but I'd guess they have to have various scripts and explicitly written out acceptance criteria and such? That's basically a form of 'tests', just in human language and human testers, not code. (I also wonder if the QA team is actually using some forms of automation that look a lot like tests, just they write/maintain them instead of "developers"?) With a team three times the size of the dev team, it's definitely not a cheap alternative, but I guess I could believe it's cheaper/more effective than trying to have automated test coverage for your code (or a combo of much smaller QA team with some test coverage), like I could believe there is some context where that's true, it seems unlikely to me it will be widely true. But whatever works. The number of software development projects that lack either sophisticated QA operations like that or good test coverage is probably bigger than those doing either though.

jbob2000 6y ago
That's a good point - we're still doing TDD, just with "human code" instead of computer code. You're correct that they write out explicit test cases for each of the acceptance criteria. It's not cheaper than developers doing the testing, but it's more wholesome. They will test exactly how a user operates, with no regards for a software's boundaries. If part of the requirement is fulfilled by another team's software, they will test that other team's work. This works great for my team since we are highly integrated with the rest of the enterprise.
- meheleventyone 6y ago
  The other amazing thing about proper QA testing that automated testing doesn't do so well is that they have the ability to go off script. Working in games the number of times I've built some feature or designed a level and thought I had tested it thoroughly only to have QA break it to pieces is very high! Your assumptions versus the assumptions of QA people and players are very different. A single, technically proficient QA expert on a team can be an incredible asset. Back that with a larger team to regression, smoke and otherwise test things and you'll not only find a load of bugs but also get early feedback on design. Automated testing definitely has a place. Libraries are a great example. There isn't really an end-user interface to test, it's not the conglomerate of much code and you basically need a test harness to even run your code. The downside is that you're typically back to only testing your own assumptions.
sumtechguy 6y ago
It is a fairly traditional way of doing it. TDD usually means you kinda know what is going on up front. If you work in a org where the sales guy can make up a feature and you need it done yesterday that can be a tough sell that you need time to write tests 'thats what we got QA for'. The refactor at this point is a daunting task. It would even be a decently expensive one. What comes out on the other end is effectively from the end users point of view, the same. I personally like working with a decent QA team. They challenge you to do better. They take a special glee in breaking your code in ways you did not think of. You can also use their test plans to write automated tests. So that way they can go think of more devious ways to break your code. Also sometimes developers can go off the deep end and over do things. It is nice to have a semi neutral third party saying what is important to test or not. Also one thing to keep in mind is many of these integration testing frameworks are basically tedious coding exercises. Especially if you are external API heavy. > it's definitely not a cheap alternative You may have hit on why many orgs like the idea of TDD. It pushes the idea that I have someone who can write code well they can write the tests too. Skipping over the fact that takes time and energy away from other things.

throw1234651234 6y ago

That's the only appeal of writing tests for non-critical functionality for me. If I know I have to write a test, I am likely to make a very clean method with a clear input / output. So it almost automatically follows SRP and is a pure function when I know it has to be tested.