WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™)
-
@GuyWhoKilledBear said in The Official Funny Stuff Thread™:
@Gąska said in The Official Funny Stuff Thread™:
@GuyWhoKilledBear TDD is work organization thing, not technology thing. And there's no such term as Continuous Development - CD means Deployment. "CI with TDD" makes as much sense as "programming in HTML". I know what they mean but they're wrong. And I highly doubt they practice TDD anyway.
"Continuous Integration" is the term they meant, which is why they called it CI and not CD. ("Continuous Development" was my typo.)
I know that in principle you can do TDD by hand without any tool support. It would be dumb, but you could do CI that way. You could do any methodology like that.
I think from the context of the post, it's obvious that they meant that "configuring a server to help developers do TDD" is a different job than "be a developer and do TDD."
Tools are irrelevant. TDD is methodology. It's not about WHAT you do, it's about HOW you do it. It's about whether you write tests before or after implementation. The end result of doing TDD or not doing TDD may very well be identical, and in simple cases it often is. TDD has nothing to do with CI, they're two separate concepts that both relate to tests. There's nothing CI about writing tests before code, and there's nothing TDD about running tests after every commit.
-
@Gąska except for the part where they are complementary practices, meathead.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Tools are irrelevant. TDD is methodology. It's not about WHAT you do, it's about HOW you do it.
Ahem:
@GuyWhoKilledBear said in The Official Funny Stuff Thread™:
I know that in principle you can do TDD by hand without any tool support. It would be dumb, but you could do CI that way. You could do any methodology like that.
-
@boomzilla did you even read what he said, or did you just spot words "without any tool" and assumed it's somehow relevant to the point I'm making?
Let me try again: if @GuyWhoKilledBear thinks CI helps with TDD in any way whatsoever, he doesn't understand what TDD is.
-
@Gąska it sure as hell helps with verifying TDD compliance
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@GuyWhoKilledBear said in The Official Funny Stuff Thread™:
@Gąska said in The Official Funny Stuff Thread™:
@GuyWhoKilledBear TDD is work organization thing, not technology thing. And there's no such term as Continuous Development - CD means Deployment. "CI with TDD" makes as much sense as "programming in HTML". I know what they mean but they're wrong. And I highly doubt they practice TDD anyway.
"Continuous Integration" is the term they meant, which is why they called it CI and not CD. ("Continuous Development" was my typo.)
I know that in principle you can do TDD by hand without any tool support. It would be dumb, but you could do CI that way. You could do any methodology like that.
I think from the context of the post, it's obvious that they meant that "configuring a server to help developers do TDD" is a different job than "be a developer and do TDD."
Tools are irrelevant. TDD is methodology. It's not about WHAT you do, it's about HOW you do it. It's about whether you write tests before or after implementation. The end result of doing TDD or not doing TDD may very well be identical, and in simple cases it often is. TDD has nothing to do with CI, they're two separate concepts that both relate to tests. There's nothing CI about writing tests before code, and there's nothing TDD about running tests after every commit.
Look man.
My organization uses tooling from the stone age. And also management practices from the stone age.
My organization doesn't do TDD. But if we did it correctly, once the tests were written, we'd be able to use it to produce rough schedule estimates. Which is something my management would want to do.
Because we use stone age tooling, what this would inevitably turn into is that we'd write the tests in whatever testing framework we'd use, and then we'd manually transpose them into a spreadsheet that my management would actually look at. And sometimes there'd be transcription errors and often they'd be out of date.
It's SUPER EASY for the tests on that spreadsheet to not reflect the tests created as part of the TDD process (by developers writing them.)
Microsoft makes a product that, among other things, tracks TDD tests. Part of that tracking is ensuring that the tests are the same tests throughout the project. It means that the TDD-generated tests are the same as the CI tests are the same as the tests on the management-readable dashboard.
CI doesn't help with TDD. But if you're doing them both, you should be using the same set of tests. CI servers anticipate this and include features to manage the tests that are the output of your TDD process.
The point of the post, which you seem to agree with, is that "administering a CI server" is a different job than "developing software."
-
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
My organization doesn't do TDD. But if we did it correctly, once the tests were written, we'd be able to use it to produce rough schedule estimates. Which is something my management would want to do.
That's not how this works, that's not how any of this works. You can't have all tests written before you start working on implementation. If your organization did TDD correctly, you'd write one test, then write enough implementation for this test to pass, then add one more test, then write just enough implementation for both tests to pass, then add another test, write implementation, then add a test and so on. This is what TDD is about. Having all tests implemented before you start working on implementation is not what TDD is about.
Microsoft makes a product that, among other things, tracks TDD tests. Part of that tracking is ensuring that the tests are the same tests throughout the project. It means that the TDD-generated tests are the same as the CI tests are the same as the tests on the management-readable dashboard.
I don't even get what "TDD tests" is supposed to mean, and how it could ever be any different from "CI tests". You have unit tests and system tests and whatever and they're all part of the project itself. CI runs the tests of the project. TDD is about writing tests for the project right before writing implementation. There isn't anything to manage here, other than the CI server.
The point of the post, which you seem to agree with, is that "administering a CI server" is a different job than "developing software."
Yes, that much we can agree.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
This is what TDD is about.
Except that if you know multiple test cases you want to pass, it makes sense to write them down now anyway instead of insisting on going off and trying to implement the code between each case. Which isn't to say that all tests must be written before any implementation, but rather the looser constraint that test cases should be written prior to the implementation of a section of code.
The thing that annoys me so much about methodology advocates (which you sound rather like) is that they often claim that the methodology, being Holy Writ, means that common sense can be parked at the door.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla did you even read what he said, or did you just spot words "without any tool" and assumed it's somehow relevant to the point I'm making?
No assumptions. Based entirely on the words. He said that good tooling makes TDD easier to implement.
Let me try again: if @GuyWhoKilledBear thinks CI helps with TDD in any way whatsoever, he doesn't understand what TDD is.
I think you've assumed a meaning of "helps" that is far too narrow. SNAFU.
-
@dkf said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
The thing that annoys me so much about methodology advocates (which you sound rather like) is that they often claim that the methodology, being Holy Writ, means that common sense can be parked at the door.
I'm tempted to create multiple fake accounts to upvote this like 50 times.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
My organization doesn't do TDD. But if we did it correctly, once the tests were written, we'd be able to use it to produce rough schedule estimates. Which is something my management would want to do.
That's not how this works, that's not how any of this works. You can't have all tests written before you start working on implementation. If your organization did TDD correctly, you'd write one test, then write enough implementation for this test to pass, then add one more test, then write just enough implementation for both tests to pass, then add another test, write implementation, then add a test and so on. This is what TDD is about. Having all tests implemented before you start working on implementation is not what TDD is about.
Remember the part about stone age management?
Microsoft makes a product that, among other things, tracks TDD tests. Part of that tracking is ensuring that the tests are the same tests throughout the project. It means that the TDD-generated tests are the same as the CI tests are the same as the tests on the management-readable dashboard.
I don't even get what "TDD tests" is supposed to mean, and how it could ever be any different from "CI tests". You have unit tests and system tests and whatever and they're all part of the project itself. CI runs the tests of the project. TDD is about writing tests for the project right before writing implementation. There isn't anything to manage here, other than the CI server.
They could be different if you fuck it up. The tooling makes sure that every time you say "the tests," you and everyone else means the same thing. Without a tool that synchronizes "the tests," you're putting the same data into multiple systems and you're vulnerable to transcription errors and staleness.
You've got to understand that some organizations are dumb.
-
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
They could be different if you fuck it up. The tooling makes sure that every time you say "the tests," you and everyone else means the same thing. Without a tool that synchronizes "the tests," you're putting the same data into multiple systems and you're vulnerable to transcription errors and staleness.
One way to look at it is that you use TDD on a development branch, and then those tests that were written for that then go on to form (at least some of) the tests run by the CI environment. CI doesn't really say what the tests should be, but does say that if you have them, they should be run on every commit (and encourages practices that lead to branches being checked for whether they work prior to the work on them becoming mainstream, whether by merging, rebasing or squashing). OTOH, TDD says what the tests should be (approximately, on a meta-level) but doesn't say really when you should check them except during the active development process; it doesn't say that the tests should go on to accompany the code despite that being a really good idea.
Two great tastes that go well together.
-
@dkf said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
This is what TDD is about.
Except that if you know multiple test cases you want to pass, it makes sense to write them down now anyway instead of insisting on going off and trying to implement the code between each case.
I never said TDD makes sense.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@dkf said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
This is what TDD is about.
Except that if you know multiple test cases you want to pass, it makes sense to write them down now anyway instead of insisting on going off and trying to implement the code between each case.
I never said TDD makes sense.
Good. The notion of making sense suffers from circular regress anyway.
-
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Microsoft makes a product that, among other things, tracks TDD tests. Part of that tracking is ensuring that the tests are the same tests throughout the project. It means that the TDD-generated tests are the same as the CI tests are the same as the tests on the management-readable dashboard.
I don't even get what "TDD tests" is supposed to mean, and how it could ever be any different from "CI tests". You have unit tests and system tests and whatever and they're all part of the project itself. CI runs the tests of the project. TDD is about writing tests for the project right before writing implementation. There isn't anything to manage here, other than the CI server.
They could be different if you fuck it up. The tooling makes sure that every time you say "the tests," you and everyone else means the same thing. Without a tool that synchronizes "the tests," you're putting the same data into multiple systems and you're vulnerable to transcription errors and staleness.
But why do you even have multiple systems to care about? The tests only live in the project's code repository, there is no other set of "the tests" to talk about but the ones that are in the project's code repository. There's no place for any tooling here because there's nothing the tools could possibly do to help with anything.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
There's no place for any tooling here because there's nothing the tools could possibly do to help with anything.
TDMSYR
Now tell us how IDEs don't help with anything.
-
@boomzilla I think you've assumed a meaning of "here" that is far too wide.
-
@Gąska so it doesn't include TDD? Seriously, how can you say that having tooling won't help you do something? That's an honest question because it really doesn't make any sense to me.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
That's an honest question
I don't believe you. You completely missed that what I was replying to was:
Without a tool that synchronizes "the tests," you're putting the same data into multiple systems
Either you don't understand what this discussion is about, or you pretend to not understand so you can say "ZOMG @Gąska said programming tools are useless, I wonder how he even compiles his code". In both cases, answering your question is pointless.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
That's an honest question
I don't believe you.
You can choose to be wrong.
You completely missed that what I was replying to was:
Without a tool that synchronizes "the tests," you're putting the same data into multiple systems
Either you don't understand what this discussion is about, or you pretend to not understand so you can say "ZOMG @Gąska said programming tools are useless, I wonder how he even compiles his code". In both cases, answering your question is pointless.
I've said that I don't understand what you're talking about here now a couple of times (remember when you said that I should do this)...admittedly the first time was kind of snarky and not very explicit.
He's saying that without the CI, how do you know what's going on? You're relying on individuals to run tests themselves. And maybe they run theirs on a branch but then don't when it gets merged. Or other scenarios. Or maybe they just don't run it, because they're lazy, get distracted, hate their job, etc, etc.
So I really have no idea why you don't think having, e.g., CI set up wouldn't help a team with implementing TDD.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I've said that I don't understand what you're talking about here
Not just me, you don't understand @GuyWhoKilledBear either.
He's saying that without the CI, how do you know what's going on?
No, that's not what he's saying. He's saying there are some specialized tools, e.g. the one from Microsoft, which lets you... synchronize test sets? Between the project and CI? And requirements spec? I think? I'm not sure either what he's saying. How could CI have different tests from the ones developers are run themselves if all that CI does is run the same commands that developers run themselves?
And anyway. It doesn't matter whether you know what's going on or not. Knowing what's going on is not part of TDD. TDD is only about writing tests, one at a time, immediately before implementation. That's the entire scope of TDD, and the idea is to get rid of any preconceived image of how the code should be structured and let the tests themselves guide you. It's a stupid idea, yes, but it is what it is - and anything that isn't directly related to writing tests or writing implementation is not related to TDD.
Basically, what I'm saying is that words have meanings.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Not just me, you don't understand @GuyWhoKilledBear either.
We definitely disagree on what he's saying.
And anyway. It doesn't matter whether you know what's going on or not. Knowing what's going on is not part of TDD. TDD is only about writing tests, one at a time, immediately before implementation. That's the entire scope of TDD, and the idea is to get rid of any preconceived image of how the code should be structured and let the tests themselves guide you. It's a stupid idea, yes, but it is what it is - and anything that isn't directly related to writing tests or writing implementation is not related to TDD.
I see that my initial surmise was correct: you've got a bad definition of "help." Being able to monitor developer activity and keep them in line will absolutely help you implement TDD. Which was what he said initially. All this argle bargle about "YOU CAN'T TALK ABOUT ANYTHING BESIDES WRITING THE TESTS BEFORE YOU CODE" is your own malfunction.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Microsoft makes a product that, among other things, tracks TDD tests. Part of that tracking is ensuring that the tests are the same tests throughout the project. It means that the TDD-generated tests are the same as the CI tests are the same as the tests on the management-readable dashboard.
I don't even get what "TDD tests" is supposed to mean, and how it could ever be any different from "CI tests". You have unit tests and system tests and whatever and they're all part of the project itself. CI runs the tests of the project. TDD is about writing tests for the project right before writing implementation. There isn't anything to manage here, other than the CI server.
They could be different if you fuck it up. The tooling makes sure that every time you say "the tests," you and everyone else means the same thing. Without a tool that synchronizes "the tests," you're putting the same data into multiple systems and you're vulnerable to transcription errors and staleness.
But why do you even have multiple systems to care about?
Because my management is dumb. If we were smarter, we'd have one system. That's kind of the point.
The tests only live in the project's code repository, there is no other set of "the tests" to talk about but the ones that are in the project's code repository. There's no place for any tooling here because there's nothing the tools could possibly do to help with anything.
For one thing, I've had to explain to people (and their boss) why they need to use a code repository rather than a bunch of files on the share drive in the first place as recently as 2016.
It is an accepted expectation where I work that there's going to be a bunch of dumb duplication when we do stuff.
If someone who's not directly involved in running the tests needs to see the tests (whether it's to see whether they pass or even to see if they've been written yet), they might not be equipped to look at the actual code repository. (Either "they don't have the training" or "they don't have the tools installed.")
If you're my organization, that means you duplicate the data in a different system. A smarter organization would use a tool to automate that duplication.
-
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
For one thing, I've had to explain to people (and their boss) why they need to use a code repository rather than a bunch of files on the share drive in the first place as recently as 2016.
So, yeah, I hadn't fully picked up on this aspect...maybe because I didn't believe it. I stand by my conclusion, however. Especially since a version control system is another kind of tooling.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
For one thing, I've had to explain to people (and their boss) why they need to use a code repository rather than a bunch of files on the share drive in the first place as recently as 2016.
So, yeah, I hadn't fully picked up on this aspect...maybe because I didn't believe it. I stand by my conclusion, however. Especially since a version control system is another kind of tooling.
Yeah, like I said. Stone. Age.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I see that my initial surmise was correct: you've got a bad definition of "help."
And you seem to have a bad definition of TDD.
Being able to monitor developer activity and keep them in line will absolutely help you implement TDD.
How exactly? Do you monitor them in real-time to make sure they have at least one failing test on their local machine at any time they touch implementation code? Because that's the only kind of monitoring which could help with TDD.
As far as TDD is concerned, once implementation is done, the test could never be run again. You could throw them out entirely after the fact, even. Because TDD is about shaping implementation with the tests, not about testing itself. And I already know you're going to misread this paragraph as "@Gąska says we should delete all tests after we're done with implementation, LOL what a moron". No, this is not what I'm saying. I'm just explaining what TDD is. TDD is one specific methodology that does one specific thing, and everything else discussed in this thread is beneath TDD's scope.
Yes, it is useful to have CI. Yes, it is useful to make sure CI runs all the tests it should. Yes, there are tools that can help you with that. Yes, it is useful to list required test cases in requirements documentation. Yes, it is useful to have tools that match the test cases from requirements to the test cases in code. None of that has anything to do with TDD.
-
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Microsoft makes a product that, among other things, tracks TDD tests. Part of that tracking is ensuring that the tests are the same tests throughout the project. It means that the TDD-generated tests are the same as the CI tests are the same as the tests on the management-readable dashboard.
I don't even get what "TDD tests" is supposed to mean, and how it could ever be any different from "CI tests". You have unit tests and system tests and whatever and they're all part of the project itself. CI runs the tests of the project. TDD is about writing tests for the project right before writing implementation. There isn't anything to manage here, other than the CI server.
They could be different if you fuck it up. The tooling makes sure that every time you say "the tests," you and everyone else means the same thing. Without a tool that synchronizes "the tests," you're putting the same data into multiple systems and you're vulnerable to transcription errors and staleness.
But why do you even have multiple systems to care about?
Because my management is dumb. If we were smarter, we'd have one system. That's kind of the point.
The tests only live in the project's code repository, there is no other set of "the tests" to talk about but the ones that are in the project's code repository. There's no place for any tooling here because there's nothing the tools could possibly do to help with anything.
For one thing, I've had to explain to people (and their boss) why they need to use a code repository rather than a bunch of files on the share drive in the first place as recently as 2016.
It is an accepted expectation where I work that there's going to be a bunch of dumb duplication when we do stuff.
If someone who's not directly involved in running the tests needs to see the tests (whether it's to see whether they pass or even to see if they've been written yet), they might not be equipped to look at the actual code repository. (Either "they don't have the training" or "they don't have the tools installed.")
If you're my organization, that means you duplicate the data in a different system. A smarter organization would use a tool to automate that duplication.
Okay, that makes sense. At least as much sense as it can make in an organization that dumb. Still, none of that is related to TDD at all.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Microsoft makes a product that, among other things, tracks TDD tests. Part of that tracking is ensuring that the tests are the same tests throughout the project. It means that the TDD-generated tests are the same as the CI tests are the same as the tests on the management-readable dashboard.
I don't even get what "TDD tests" is supposed to mean, and how it could ever be any different from "CI tests". You have unit tests and system tests and whatever and they're all part of the project itself. CI runs the tests of the project. TDD is about writing tests for the project right before writing implementation. There isn't anything to manage here, other than the CI server.
They could be different if you fuck it up. The tooling makes sure that every time you say "the tests," you and everyone else means the same thing. Without a tool that synchronizes "the tests," you're putting the same data into multiple systems and you're vulnerable to transcription errors and staleness.
But why do you even have multiple systems to care about?
Because my management is dumb. If we were smarter, we'd have one system. That's kind of the point.
The tests only live in the project's code repository, there is no other set of "the tests" to talk about but the ones that are in the project's code repository. There's no place for any tooling here because there's nothing the tools could possibly do to help with anything.
For one thing, I've had to explain to people (and their boss) why they need to use a code repository rather than a bunch of files on the share drive in the first place as recently as 2016.
It is an accepted expectation where I work that there's going to be a bunch of dumb duplication when we do stuff.
If someone who's not directly involved in running the tests needs to see the tests (whether it's to see whether they pass or even to see if they've been written yet), they might not be equipped to look at the actual code repository. (Either "they don't have the training" or "they don't have the tools installed.")
If you're my organization, that means you duplicate the data in a different system. A smarter organization would use a tool to automate that duplication.
Okay, that makes sense. At least as much sense as it can make in an organization that dumb. Still, none of that is related to TDD at all.
Is intrinsically vs is, no, actually, don't clarify, it's better this way.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I see that my initial surmise was correct: you've got a bad definition of "help."
And you seem to have a bad definition of TDD.
Being able to monitor developer activity and keep them in line will absolutely help you implement TDD.
How exactly? Do you monitor them in real-time to make sure they have at least one failing test on their local machine at any time they touch implementation code? Because that's the only kind of monitoring which could help with TDD.
No, you're just continuing to prove me exactly correct. You're hyperfocused on the definition of TDD and not on what's helpful to actually implementing it, which was the point made originally.
And if you still don't believe me, maybe you'll believe this guy:
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Yes, it is useful to have CI. Yes, it is useful to make sure CI runs all the tests it should. Yes, there are tools that can help you with that. Yes, it is useful to list required test cases in requirements documentation. Yes, it is useful to have tools that match the test cases from requirements to the test cases in code.
Except that he then steps on his dick with this irrelevance:
None of that has anything to do with TDD.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I see that my initial surmise was correct: you've got a bad definition of "help."
And you seem to have a bad definition of TDD.
Being able to monitor developer activity and keep them in line will absolutely help you implement TDD.
How exactly? Do you monitor them in real-time to make sure they have at least one failing test on their local machine at any time they touch implementation code? Because that's the only kind of monitoring which could help with TDD.
No, you're just continuing to prove me exactly correct.
And you're continuing to prove me exactly correct. Funny how that works.
You're hyperfocused on the definition of TDD and not on what's helpful to actually implementing it, which was the point made originally.
Look. TDD means one specific thing. ANYTHING THAT HELPS WITH THAT ONE SPECIFIC THING IN ANY WAY WHATSOEVER IS ALSO HELPFUL FOR TDD. The thing is, NONE of the things mentioned help with THAT ONE SPECIFIC THING that TDD is all about.
Prepare for a car analogy, because I'm out of ideas how else I can get this simple idea through your thick skull.
Let's say you have a race car and participate in a race. The ultimate goal is to get the fastest time possible. You do that by going as fast as possible, as much as possible. One factor is acceleration - the faster you accelerate, the faster you go (I mean, obviously). But that's not the whole story - the track also has turns, and you have to slow down to stay on track. The stronger your brakes, the less time you spend braking, and if brake less, you can go fast on a straight longer, which lets you get an even better time than if you relied on acceleration alone.
Your argument is that brakes increase acceleration.
-
@Gribnit said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska it sure as hell helps with verifying TDD compliance
How so?
You write a test without any implementation. If you check that in, you have a failing test, something CI systems usually don't see as a desirable state. If you don't check it in, CI doesn't know it exists and thus can't possibly be of any help.
Then you write your implementation. If you check that in with your test, you could have written them in any order, the TDD way or the non-TDD way, CI doesn't know and thus can't possibly be of any help.
-
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
For one thing, I've had to explain to people (and their boss) why they need to use a code repository rather than a bunch of files on the share drive in the first place as recently as 2016.
You don't mail your code to each other in zip files? Cutting edge.
[edit]
That's a real thing, from one place I worked in about 6 years ago.
No, not a tiny garage shop, a huge corp with thousands of employees.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I see that my initial surmise was correct: you've got a bad definition of "help."
And you seem to have a bad definition of TDD.
Being able to monitor developer activity and keep them in line will absolutely help you implement TDD.
How exactly? Do you monitor them in real-time to make sure they have at least one failing test on their local machine at any time they touch implementation code? Because that's the only kind of monitoring which could help with TDD.
No, you're just continuing to prove me exactly correct.
And you're continuing to prove me exactly correct. Funny how that works.
Well, I agree with the basic statement. The problem is that the basic statement was irrelevant here.
You're hyperfocused on the definition of TDD and not on what's helpful to actually implementing it, which was the point made originally.
Look. TDD means one specific thing. ANYTHING THAT HELPS WITH THAT ONE SPECIFIC THING IN ANY WAY WHATSOEVER IS ALSO HELPFUL FOR TDD. The thing is, NONE of the things mentioned help with THAT ONE SPECIFIC THING that TDD is all about.
Except in the ways that I explained.
Prepare for a car analogy, because I'm out of ideas how else I can get this simple idea through your thick skull.
Let's say you have a race car and participate in a race. The ultimate goal is to get the fastest time possible. You do that by going as fast as possible, as much as possible. One factor is acceleration - the faster you accelerate, the faster you go (I mean, obviously). But that's not the whole story - the track also has turns, and you have to slow down to stay on track. The stronger your brakes, the less time you spend braking, and if brake less, you can go fast on a straight longer, which lets you get an even better time than if you relied on acceleration alone.
Your argument is that brakes increase acceleration.
No that's your lame strawman. I'd have finished off your analogy by saying that a judicious application of brakes could prevent crashing, which prevents you from finishing the race, etc.
This is really dumb, even for you.
-
@MrL said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
For one thing, I've had to explain to people (and their boss) why they need to use a code repository rather than a bunch of files on the share drive in the first place as recently as 2016.
You don't mail your code to each other in zip files? Cutting edge.
[edit]
That's a real thing, from one place I worked in about 6 years ago.
No, not a tiny garage shop, a huge corp with thousands of employees.Zip files get stripped out of emails by our spam filter. 90% sure that's what's stopping us from doing that.
-
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@MrL said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@GuyWhoKilledBear said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
For one thing, I've had to explain to people (and their boss) why they need to use a code repository rather than a bunch of files on the share drive in the first place as recently as 2016.
You don't mail your code to each other in zip files? Cutting edge.
[edit]
That's a real thing, from one place I worked in about 6 years ago.
No, not a tiny garage shop, a huge corp with thousands of employees.Zip files get stripped out of emails by our spam filter. 90% sure that's what's stopping us from doing that.
Yeah, it's wasteful anyway. You should paste only the changed lines to email body.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I'd have finished off your analogy by saying that a judicious application of brakes could prevent crashing, which prevents you from finishing the race, etc.
Well, if we're including things like "the company not going bankrupt" as helping with TDD, then yes, you have some kind of point. But that's such a big stretch that talking about it stops being useful. Anything and everything can help with TDD if you look at it this way. Hiring better developers, government passing corporate-friendly laws, healthy diet that makes you more energetic, better access to mental health care, workplace environment that encourages hard work - all these things help with TDD in the same way that CI does.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I'd have finished off your analogy by saying that a judicious application of brakes could prevent crashing, which prevents you from finishing the race, etc.
Well, if we're including things like "the company not going bankrupt" as helping with TDD, then yes, you have some kind of point.
I see you're finally getting around to understanding what @GuyWhoKilledBear originally said.
But that's such a big stretch that talking about it stops being useful. Anything and everything can help with TDD if you look at it this way. Hiring better developers, government passing corporate-friendly laws, healthy diet that makes you more energetic, better access to mental health care, workplace environment that encourages hard work - all these things help with TDD in the same way that CI does.
Of course, having tooling like a version control system and CI are more focused than general things, but yes, all of those are helpful, too.
Let's imagine we were in an alternate reality, where he'd phrased it differently. Maybe something like:
Not having a central VCS or CI makes it more difficult to implement TDD at my work.
Do you suppose you'd have emitted the same level of
?
-
@boomzilla yes I would (which is 0 because none of what I said qualifies as
but that's beside the point; yes I would react the same.)If the only impact your thing has on TDD is that it makes the overall work environment better so you spend less time chasing ghosts and fighting the process, and more time actually working, which in turn you may choose to spend on trying to do TDD better - then as far as I'm concerned, your thing is irrelevant to TDD.
Remember this quote from OP:
I know that in principle you can do TDD by hand without any tool support. It would be dumb
This implies two things:
- There exist tools that help with TDD process itself (so you don't have to do "TDD by hand".)
- Doing TDD process without using those tools is an inferior way of doing TDD process.
If instead that quote read as "there's no point in doing TDD without also doing other things (like CI), and you really can't do those other things without appropriate tools" - then I would agree. With the caveat that TDD itself doesn't make sense to start with.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla yes I would (which is 0 because none of what I said qualifies as
but that's beside the point; yes I would react the same.)If the only impact your thing has on TDD is that it makes the overall work environment better so you spend less time chasing ghosts and fighting the process, and more time actually working, which in turn you may choose to spend on trying to do TDD better - then as far as I'm concerned, your thing is irrelevant to TDD.
And I agree, as far as that goes. It's just...again...irrelevant to the post you initially responded to.
Remember this quote from OP:
I know that in principle you can do TDD by hand without any tool support. It would be dumb
This implies two things:
- There exist tools that help with TDD process itself (so you don't have to do "TDD by hand".)
- Doing TDD process without using those tools is an inferior way of doing TDD process.
If instead that quote read as "there's no point in doing TDD without also doing other things (like CI), and you really can't do those other things without appropriate tools" - then I would agree. With the caveat that TDD itself doesn't make sense to start with.
Same picture thread is
-
@boomzilla I'm still waiting for an explanation what "TDD by hand" looks like and how it's different from TDD not by hand. So, not quite the same picture.
Also, if you meant that I'm essentially correct but I'm just not looking at the big picture - you could've just said that I'm essentially correct but not looking at the big picture. It would save us both a lot of time.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla I'm still waiting for an explanation what "TDD by hand" looks like and how it's different from TDD not by hand. So, not quite the same picture.
Because you don't know what CI is? How can this be? Are you also unfamiliar with IDEs? Do you program via punch cards using a sharpened pencil?
Also, if you meant that I'm essentially correct but I'm just not looking at the big picture - you could've just said that I'm essentially correct but not looking at the big picture. It would save us both a lot of time.
You could try reading my posts because I did that over and over.
-
@Gąska listen, your request to be told when you're focusing on a detail vs the big picture might help this argument, but what about every argument?
-
@boomzilla CI verifies coverage which doesn't quite verify test-first TDD.
-
@Gribnit said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla CI verifies coverage which doesn't quite verify test-first TDD.
That's true, of course. But it would catch out the people who weren't writing any tests at all.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla I'm still waiting for an explanation what "TDD by hand" looks like and how it's different from TDD not by hand. So, not quite the same picture.
Because you don't know what CI is?
Didn't we just agree that CI or lack of CI doesn't make any difference in how you perform the TDD process itself?
Are you also unfamiliar with IDEs?
Fun fact: I used to program in C++ with just a Notepad++ clone and a terminal. At work. Around 2015. For a couple years.
grepwas my Find References,find . -iname xxx | xargs meditwas my Go To Definition. I built the project by running make, run the tests by executing a shell script, and used GDB directly from command line. I found that much easier to work with than any IDE I tried (and I tried like 5 different ones), but only because that project was super weird and indexers couldn't handle it. But to be fair, it wasn't all that much harder than my home projects where I used Visual Studio.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla I'm still waiting for an explanation what "TDD by hand" looks like and how it's different from TDD not by hand. So, not quite the same picture.
Because you don't know what CI is?
Didn't we just agree that CI or lack of CI doesn't make any difference in how you perform the TDD process itself?
It probably makes no difference to the individual. But as was just discussed, CI gives management visibility on the process so that the organization doesn't slack off. If you think that this isn't a barrier to implementing TDD in an organization then you must be a hermit.
-
@boomzilla ... does this mean you're going to stop bitching about taxes?
-
@boomzilla just so we're on the same page - we're still talking about TDD by hand vs. not by hand? And you're saying that TDD not by hand means that it is enforced by a semi-automated tool that enough tests exist?
-
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla just so we're on the same page - we're still talking about TDD by hand vs. not by hand? And you're saying that TDD not by hand means that it is enforced by a semi-automated tool that enough tests exist?
Oh FFS.
I'm talking about how having good tools like a central VCS and CI promote the visibility of activities which makes it easier to keep everyone on track.
