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™):
TDD process ends when you commit. CI process starts after you commit. There's simply no point in time the two could ever interact with each other.
Oh, are you one of these people who likes a linear timeline? That's Different™.
He absolutely refuses to even consider anything outside of that as facilitating the process.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@dkf For a second I was worried you may have some kind of point and I might be missing something. But turns out you were just shitposting.
This is really a near @Gribnit level performance you've put on in this 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 so I guess when you said "sure", you actually meant no, you're not going to explain it.
Since you haven't read any previous ones, I'm not sure why you think I'd believe you that you'd read it again.
So you were lying. OK.
-
@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 so I guess when you said "sure", you actually meant no, you're not going to explain it.
Since you haven't read any previous ones, I'm not sure why you think I'd believe you that you'd read it again.
So you were lying. OK.
Yeah, he does that. It's his way of conceding.
-
@boomzilla let's clarify one thing.
I agree with everything you said EXCEPT that there exist tools that help with TDD. And every single example of a tool that helps with TDD you brought up so far was instead helping with the overall state of the project as a whole, and not TDD per se.
JIRA doesn't help with compiling. It makes it easier to arrive at the point where you're compiling by streamlining other things going on in the project, but it doesn't help with compiling itself.
Second monitor doesn't help with accurate estimations. It makes it easier to do other things so when you finally come around to doing estimations, you have more time and are more relaxed, but it doesn't help with estimations themselves.
Faster workstation doesn't help with hiring decisions. It makes other things work quicker so you're left with more time to find and consider the candidates, but it doesn't help with hiring decisions themselves.
Do you disagree with any of the above?
-
@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 so I guess when you said "sure", you actually meant no, you're not going to explain it.
Since you haven't read any previous ones, I'm not sure why you think I'd believe you that you'd read it again.
So you were lying. OK.
Keep telling yourself this.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla let's clarify one thing.
I agree with everything you said EXCEPT that there exist tools that help with TDD. And every single example of a tool that helps with TDD you brought up so far was instead helping with the overall state of the project as a whole, and not TDD per se.
The original point was "doing TDD well." Your inability to look beyond the task of writing tests and code is your problem here, as I've pointed out above.
How do you know how well you're doing?
JIRA doesn't help with compiling. It makes it easier to arrive at the point where you're compiling by streamlining other things going on in the project, but it doesn't help with compiling itself.
Second monitor doesn't help with accurate estimations. It makes it easier to do other things so when you finally come around to doing estimations, you have more time and are more relaxed, but it doesn't help with estimations themselves.
Faster workstation doesn't help with hiring decisions. It makes other things work quicker so you're left with more time to find and consider the candidates, but it doesn't help with hiring decisions themselves.
Do you disagree with any of the above?
I do not. But you're helping to make my point.
-
@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 let's clarify one thing.
I agree with everything you said EXCEPT that there exist tools that help with TDD. And every single example of a tool that helps with TDD you brought up so far was instead helping with the overall state of the project as a whole, and not TDD per se.
The original point was "doing TDD well." Your inability to look beyond the task of writing tests and code is your problem here, as I've pointed out above.
No, it's your inability to look at the purpose of TDD that's the problem here. No matter how detached from writing tests and code, if something makes it easier to achieve TDD's purpose, then I agree it helps with TDD. The thing is, CI doesn't do shit to help achieve TDD's purpose. Which is to get rid of preconceived designs of how the code will look like before you even start writing it and let thr tests guide you instead.
How do you know how well you're doing?
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
TDD is one of those things that doesn't have any measurabe metrics. The best you can do is trust your developers. Or maybe spy on them in real time to make sure they never write any implementation unless they have at least one failing test.
And just in case you forgot. I still think TDD is dumb and shouldn't be practiced at all. As opposed to CI, which is the most important thing in the world for modern software projects.
JIRA doesn't help with compiling. It makes it easier to arrive at the point where you're compiling by streamlining other things going on in the project, but it doesn't help with compiling itself.
Second monitor doesn't help with accurate estimations. It makes it easier to do other things so when you finally come around to doing estimations, you have more time and are more relaxed, but it doesn't help with estimations themselves.
Faster workstation doesn't help with hiring decisions. It makes other things work quicker so you're left with more time to find and consider the candidates, but it doesn't help with hiring decisions themselves.
Do you disagree with any of the above?
I do not. But you're helping to make my point.
OK so at least we're on the same page here.
-
@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 let's clarify one thing.
I agree with everything you said EXCEPT that there exist tools that help with TDD. And every single example of a tool that helps with TDD you brought up so far was instead helping with the overall state of the project as a whole, and not TDD per se.
The original point was "doing TDD well." Your inability to look beyond the task of writing tests and code is your problem here, as I've pointed out above.
No, it's your inability to look at the purpose of TDD that's the problem here. No matter how detached from writing tests and code, if something makes it easier to achieve TDD's purpose, then I agree it helps with TDD. The thing is, CI doesn't do shit to help achieve TDD's purpose. Which is to get rid of preconceived designs of how the code will look like before you even start writing it and let thr tests guide you instead.
And this does. Not so much from an individual perspective, of course, but for the organization.
How do you know how well you're doing?
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I guess when you said "sure", you actually meant no
Congratulations on your discovery of sarcasm.
-
@dkf said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
you one of these people who likes a linear timeline? That's Different™.
I prefer one that's more wibbly-wobbly.
-
@HardwareGeek 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™):
you one of these people who likes a linear timeline? That's Different™.
I prefer one that's more wibbly-wobbly.
I like my timeline to have twiggly bits on it where little birds can sit and sing. On their own, they're not very much at all, but together they combine like a banyan.
-
@dkf Is this a literary allusion? I don't recognize it, and DDG did not return useful search results.
-
@HardwareGeek it refers to the effective time stop that occurs when @dkf thinks. I used to get that before I broke that part.
-
@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™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla let's clarify one thing.
I agree with everything you said EXCEPT that there exist tools that help with TDD. And every single example of a tool that helps with TDD you brought up so far was instead helping with the overall state of the project as a whole, and not TDD per se.
The original point was "doing TDD well." Your inability to look beyond the task of writing tests and code is your problem here, as I've pointed out above.
No, it's your inability to look at the purpose of TDD that's the problem here. No matter how detached from writing tests and code, if something makes it easier to achieve TDD's purpose, then I agree it helps with TDD. The thing is, CI doesn't do shit to help achieve TDD's purpose. Which is to get rid of preconceived designs of how the code will look like before you even start writing it and let thr tests guide you instead.
And this does. Not so much from an individual perspective, of course, but for the organization.
Even from organization's perspective, CI still doesn't get rid of preconceived designs of how the code will look like. And none of the 114 posts in this thread so far explain how that would even work.
How do you know how well you're doing?
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
I repeat: tests are not TDD.
-
@Gąska TDD doesn't get rid of those notions at all, it just creates a mechanism by which their influence is tempered.
-
@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™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla let's clarify one thing.
I agree with everything you said EXCEPT that there exist tools that help with TDD. And every single example of a tool that helps with TDD you brought up so far was instead helping with the overall state of the project as a whole, and not TDD per se.
The original point was "doing TDD well." Your inability to look beyond the task of writing tests and code is your problem here, as I've pointed out above.
No, it's your inability to look at the purpose of TDD that's the problem here. No matter how detached from writing tests and code, if something makes it easier to achieve TDD's purpose, then I agree it helps with TDD. The thing is, CI doesn't do shit to help achieve TDD's purpose. Which is to get rid of preconceived designs of how the code will look like before you even start writing it and let thr tests guide you instead.
And this does. Not so much from an individual perspective, of course, but for the organization.
Even from organization's perspective, CI still doesn't get rid of preconceived designs of how the code will look like. And none of the 114 posts in this thread so far explain how that would even work.
I don't feel bad about accusing you of lying since you already did it to me. Also you're doing just that.
How do you know how well you're doing?
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
I repeat: tests are not TDD.
And?
-
@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™):
@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 let's clarify one thing.
I agree with everything you said EXCEPT that there exist tools that help with TDD. And every single example of a tool that helps with TDD you brought up so far was instead helping with the overall state of the project as a whole, and not TDD per se.
The original point was "doing TDD well." Your inability to look beyond the task of writing tests and code is your problem here, as I've pointed out above.
No, it's your inability to look at the purpose of TDD that's the problem here. No matter how detached from writing tests and code, if something makes it easier to achieve TDD's purpose, then I agree it helps with TDD. The thing is, CI doesn't do shit to help achieve TDD's purpose. Which is to get rid of preconceived designs of how the code will look like before you even start writing it and let thr tests guide you instead.
And this does. Not so much from an individual perspective, of course, but for the organization.
Even from organization's perspective, CI still doesn't get rid of preconceived designs of how the code will look like. And none of the 114 posts in this thread so far explain how that would even work.
I don't feel bad about accusing you of lying since you already did it to me. Also you're doing just that.
Then show me which of the 114 posts in this topic talk about preconceived designs of how the code will look like, and how CI helps getting rid of them. Because I read them all and literally none of them are, at least as far as I can see.
How do you know how well you're doing?
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
I repeat: tests are not TDD.
And?
Nothing. There's nothing more to say. "How do you even know you have tests" is not a relevant question.
-
@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™):
@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 let's clarify one thing.
I agree with everything you said EXCEPT that there exist tools that help with TDD. And every single example of a tool that helps with TDD you brought up so far was instead helping with the overall state of the project as a whole, and not TDD per se.
The original point was "doing TDD well." Your inability to look beyond the task of writing tests and code is your problem here, as I've pointed out above.
No, it's your inability to look at the purpose of TDD that's the problem here. No matter how detached from writing tests and code, if something makes it easier to achieve TDD's purpose, then I agree it helps with TDD. The thing is, CI doesn't do shit to help achieve TDD's purpose. Which is to get rid of preconceived designs of how the code will look like before you even start writing it and let thr tests guide you instead.
And this does. Not so much from an individual perspective, of course, but for the organization.
Even from organization's perspective, CI still doesn't get rid of preconceived designs of how the code will look like. And none of the 114 posts in this thread so far explain how that would even work.
I don't feel bad about accusing you of lying since you already did it to me. Also you're doing just that.
Then show me which of the 114 posts in this topic talk about preconceived designs of how the code will look like, and how CI helps getting rid of them. Because I read them all and literally none of them are, at least as far as I can see.
It's the ones where I talk about monitoring things. I know that you can't see past the commit, and that's fine. It's just dumb. Or maybe you're reading this and thinking that I'm trying to say that observing that tests exist would prove that they were written ahead of time, etc, as one does with TDD. And there we'd be in agreement that I never said that.
The point was that someone in a management / supervisory / lead role needs to be watching things. And seeing, for instance, code without tests would be a big red flag that someone isn't doing TDD. At least for people who believe that there are tests when you do TDD. More on that below.
How do you know how well you're doing?
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
I repeat: tests are not TDD.
And?
Nothing. There's nothing more to say. "How do you even know you have tests" is not a relevant question.
So you're making the stronger claim that there are no tests when you do TDD? I read that originally as, "TDD is more than writing tests." This is a spicy take.
-
@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™):
@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™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla let's clarify one thing.
I agree with everything you said EXCEPT that there exist tools that help with TDD. And every single example of a tool that helps with TDD you brought up so far was instead helping with the overall state of the project as a whole, and not TDD per se.
The original point was "doing TDD well." Your inability to look beyond the task of writing tests and code is your problem here, as I've pointed out above.
No, it's your inability to look at the purpose of TDD that's the problem here. No matter how detached from writing tests and code, if something makes it easier to achieve TDD's purpose, then I agree it helps with TDD. The thing is, CI doesn't do shit to help achieve TDD's purpose. Which is to get rid of preconceived designs of how the code will look like before you even start writing it and let thr tests guide you instead.
And this does. Not so much from an individual perspective, of course, but for the organization.
Even from organization's perspective, CI still doesn't get rid of preconceived designs of how the code will look like. And none of the 114 posts in this thread so far explain how that would even work.
I don't feel bad about accusing you of lying since you already did it to me. Also you're doing just that.
Then show me which of the 114 posts in this topic talk about preconceived designs of how the code will look like, and how CI helps getting rid of them. Because I read them all and literally none of them are, at least as far as I can see.
It's the ones where I talk about monitoring things.
See? You can speak straight after all. It wasn't that hard, was it?
I know that you can't see past the commit
I can see past the commit just fine. It's just that I don't see a connection between monitoring and getting rid of preconceived notions of how the code will be structured. If there was some way for a CEO and the board of directors to enact some decisions that over the next 10 years would gradually make the employees more and more keen on having tests guide your design instead of thinking of everything up front, that would absolutely be helping TDD.
The issue is that monitoring test counts doesn't do that. It just tells you whether you have tests and how many of them. But neither of these metrics tells you anything about TDD process.
The point was that someone in a management / supervisory / lead role needs to be watching things. And seeing, for instance, code without tests would be a big red flag that someone isn't doing TDD.
And seeing in a time tracker that your employee isn't at work is also a big red flag that someone isn't doing TDD (because they're not doing any work at all). Does that make a time tracker a TDD tool?
How do you know how well you're doing?
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
I repeat: tests are not TDD.
And?
Nothing. There's nothing more to say. "How do you even know you have tests" is not a relevant question.
So you're making the stronger claim that there are no tests when you do TDD?
And you say I can't read.
No, I'm making a claim that you can end up with having tests in more ways than just TDD, and so monitoring doesn't tell you whether TDD was used or not. That's why the question was irrelevant.
And as I mentioned previously, it is theoretically possible to practice TDD without ever committing a single test into the repository. It would be idiotic and no one ever does that, but it's still theoretically possible. Because existence of tests is the least important thing about TDD. The point of TDD is to not have up front designs of the code. CI doesn't help with that.
-
@Gąska the point of tdd is to make the tests into the design, more than to alter the notions of how to write code. Nothing can do the latter as the notions simply migrate into the testlands.
-
@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™):
@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™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla let's clarify one thing.
I agree with everything you said EXCEPT that there exist tools that help with TDD. And every single example of a tool that helps with TDD you brought up so far was instead helping with the overall state of the project as a whole, and not TDD per se.
The original point was "doing TDD well." Your inability to look beyond the task of writing tests and code is your problem here, as I've pointed out above.
No, it's your inability to look at the purpose of TDD that's the problem here. No matter how detached from writing tests and code, if something makes it easier to achieve TDD's purpose, then I agree it helps with TDD. The thing is, CI doesn't do shit to help achieve TDD's purpose. Which is to get rid of preconceived designs of how the code will look like before you even start writing it and let thr tests guide you instead.
And this does. Not so much from an individual perspective, of course, but for the organization.
Even from organization's perspective, CI still doesn't get rid of preconceived designs of how the code will look like. And none of the 114 posts in this thread so far explain how that would even work.
I don't feel bad about accusing you of lying since you already did it to me. Also you're doing just that.
Then show me which of the 114 posts in this topic talk about preconceived designs of how the code will look like, and how CI helps getting rid of them. Because I read them all and literally none of them are, at least as far as I can see.
It's the ones where I talk about monitoring things.
See? You can speak straight after all. It wasn't that hard, was it?
Never was.
-
@boomzilla except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
Such as?
I dunno...I'm sure I used a bunch of snark out of frustration with your anti-communication. But pretty sure that was after you went full retard and started telling me I was lying when you ignored what I wrrote.
-
@HardwareGeek said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Is this a literary allusion?
If it is, it's a very very mangled misremembered one. I was referring to the branch-and-merge strategy of git, perhaps cross-referenced with ideas from CTL* temporal logic. The idea is that time isn't a line, but rather a braid of streams that split apart and merge.
I then remembered this:
and all mixed it up and stapled some more random poetic imagery to it.
-
@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 except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
Such as?
@HardwareGeek 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™):
I guess when you said "sure", you actually meant no
Congratulations on your discovery of sarcasm.
-
@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 except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
Such as?
@HardwareGeek 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™):
I guess when you said "sure", you actually meant no
Congratulations on your discovery of sarcasm.
I mean...it was snarky, but I was actually agreeing there. And then I pointed out that you'd been ignoring the answers you were asking for, so perhaps you can understand, once again, my frustration with your intentional anti-communication.
-
@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 except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
Such as?
@HardwareGeek 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™):
I guess when you said "sure", you actually meant no
Congratulations on your discovery of sarcasm.
TBH, I'm not really sure if anything @boomzilla was meant as sarcasm; I've been skipping or skimming vast amounts of this argument. But "'sure' meant 'no'" is likely sarcasm.
-
Clearly, @Gąska needs to pioneer Rant Driven Development. He and Blakey could be world leaders
-
@Jaloopa we'd kill each other on
dayhour one.
-
@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™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
Such as?
@HardwareGeek 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™):
I guess when you said "sure", you actually meant no
Congratulations on your discovery of sarcasm.
I mean...it was snarky, but I was actually agreeing there. And then I pointed out that you'd been ignoring the answers you were asking for, so perhaps you can understand, once again, my frustration with your intentional anti-communication.
Assuming I was actuallly ignoring anything, yes, it's understandable. But that assumption is wrong. I explained over and over again why "checking if you have tests at all" does not help in the process of TDD itself, and therefore doing TDD without it is no different from doing TDD with it. And so calling those monitoring tools "TDD tools" is wrong, and calling using them "tool-assisted TDD“ is wrong too. You were ignoring that way more than I was ignoring anything you said.
-
@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™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
Such as?
@HardwareGeek 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™):
I guess when you said "sure", you actually meant no
Congratulations on your discovery of sarcasm.
I mean...it was snarky, but I was actually agreeing there. And then I pointed out that you'd been ignoring the answers you were asking for, so perhaps you can understand, once again, my frustration with your intentional anti-communication.
Assuming I was actuallly ignoring anything, yes, it's understandable. But that assumption is wrong. I explained over and over again why "checking if you have tests at all" does not help in the process of TDD itself, and therefore doing TDD without it is no different from doing TDD with it. And so calling those monitoring tools "TDD tools" is wrong, and calling using them "tool-assisted TDD“ is wrong too. You were ignoring that way more than I was ignoring anything you said.
I asked you about this before and I don't recall getting an anwser. Are you saying there are no tests or something? How else could this be interpreted?
-
@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™):
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
TDD is like the Catholic catechism that (yeah, simplifying a bit here for the sake of it) says you're supposed to go into marriage as a virgin and then have sex in order to procreate. A bit stupid but there are people who say it's got something going for it. CI is basically checking whether people have sex after marriage, and you're proposing that as a way to verify and facilitate marriages in accordance with the Catholic catechism.
-
@LaoC 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™):
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
TDD is like the Catholic catechism that (yeah, simplifying a bit here for the sake of it) says you're supposed to go into marriage as a virgin and then have sex in order to procreate. A bit stupid but there are people who say it's got something going for it. CI is basically checking whether people have sex after marriage, and you're proposing that as a way to verify and facilitate marriages in accordance with the Catholic catechism.
In fact I am not.
As I already said, CI will catch out the people who don't write any tests. Or who don't bother to make their tests pass. That is an important part of TDD as I understand it. Not sufficient, but certainly necessary.
You can additionally use a VCS to check stuff and see if people are writing the tests first.
How is this difficult to understand?
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
You can additionally use a VCS to check stuff and see if people are writing the tests first.
The easiest way to do that is to hook a code coverage tool into the test running in CI. With that, you can easily verify just how much of the code is actually (automatically) tested. And for @Gąska and his interpretation of TDD, that ought to be 100% straight away, yes?
-
@boomzilla Wasn't part of his point that you can do TDD without ever committing your tests? Yes, it would be a stupid way to do it but
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@LaoC 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™):
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
TDD is like the Catholic catechism that (yeah, simplifying a bit here for the sake of it) says you're supposed to go into marriage as a virgin and then have sex in order to procreate. A bit stupid but there are people who say it's got something going for it. CI is basically checking whether people have sex after marriage, and you're proposing that as a way to verify and facilitate marriages in accordance with the Catholic catechism.
In fact I am not.
As I already said, CI will catch out the people who don't
write any testshave sex. Or who don't bother tomake their tests passprocreate. That is an important part ofTDDthe catechism as I understand it. Not sufficient, but certainly necessary.Yes, many people think marriage should usually involve sex. What sets the Catholics (and a few others) apart is the virginity-before bit.
You can additionally use a VCS to check stuff and see if people are writing the tests first.
How is this difficult to understand?
CI facilitates TDD because you can use some other thing to manually check for TDD compliant procedures that upset the CI system. OK, that's easy to understand, it's just dumb.
-
@Jaloopa said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla Wasn't part of his point that you can do TDD without ever committing your tests? Yes, it would be a stupid way to do it but
Well, sure, you can. You can do lots of things. Again, we're back to the original claim that it's easier to do TDD well if you have some of these tools. And my point is that without them it's very difficult to monitor the process and make any corrections in order to keep in the "doing it well" zone.
-
@LaoC 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™):
@LaoC 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™):
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
TDD is like the Catholic catechism that (yeah, simplifying a bit here for the sake of it) says you're supposed to go into marriage as a virgin and then have sex in order to procreate. A bit stupid but there are people who say it's got something going for it. CI is basically checking whether people have sex after marriage, and you're proposing that as a way to verify and facilitate marriages in accordance with the Catholic catechism.
In fact I am not.
As I already said, CI will catch out the people who don't
write any testshave sex. Or who don't bother tomake their tests passprocreate. That is an important part ofTDDthe catechism as I understand it. Not sufficient, but certainly necessary.Yes, many people think marriage should usually involve sex. What sets the Catholics (and a few others) apart is the virginity-before bit.
Yes, and?
You can additionally use a VCS to check stuff and see if people are writing the tests first.
How is this difficult to understand?
CI facilitates TDD because you can use some other thing to manually check for TDD compliant procedures that upset the CI system. OK, that's easy to understand, it's just dumb.
Yes, what you said sounds dumb and also demonstrates that you didn't understand what I said. Unless you believe that someone not writing passing tests could be following 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™):
@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 except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
Such as?
@HardwareGeek 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™):
I guess when you said "sure", you actually meant no
Congratulations on your discovery of sarcasm.
I mean...it was snarky, but I was actually agreeing there. And then I pointed out that you'd been ignoring the answers you were asking for, so perhaps you can understand, once again, my frustration with your intentional anti-communication.
Assuming I was actuallly ignoring anything, yes, it's understandable. But that assumption is wrong. I explained over and over again why "checking if you have tests at all" does not help in the process of TDD itself, and therefore doing TDD without it is no different from doing TDD with it. And so calling those monitoring tools "TDD tools" is wrong, and calling using them "tool-assisted TDD“ is wrong too. You were ignoring that way more than I was ignoring anything you said.
I asked you about this before and I don't recall getting an anwser.
Oh look, someone doesn't read other people's post!
Are you saying there are no tests or something?
I literally just answered this very question 5 posts ago. All those quips about me not reading what you say really look like psychological projection now.
How else could this be interpreted?
"Test count monitoring is way too high-level, coarse-grained and unspecific to be a useful tool in checking whether TDD process is being followed." For example.
-
@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™):
@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 except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
Such as?
@HardwareGeek 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™):
I guess when you said "sure", you actually meant no
Congratulations on your discovery of sarcasm.
I mean...it was snarky, but I was actually agreeing there. And then I pointed out that you'd been ignoring the answers you were asking for, so perhaps you can understand, once again, my frustration with your intentional anti-communication.
Assuming I was actuallly ignoring anything, yes, it's understandable. But that assumption is wrong. I explained over and over again why "checking if you have tests at all" does not help in the process of TDD itself, and therefore doing TDD without it is no different from doing TDD with it. And so calling those monitoring tools "TDD tools" is wrong, and calling using them "tool-assisted TDD“ is wrong too. You were ignoring that way more than I was ignoring anything you said.
I asked you about this before and I don't recall getting an anwser.
Oh look, someone doesn't read other people's post!
Are you saying there are no tests or something?
I literally just answered this very question 5 posts ago. All those quips about me not reading what you say really look like psychological projection now.
OK, I guess it was too far apart from when I asked that. Also you were back apparently denying the existence of tests.
How else could this be interpreted?
"Test count monitoring is way too high-level, coarse-grained and unspecific to be a useful tool in checking whether TDD process is being followed." For example.
I see. So you're firmly in the camp of the good is the enemy of the perfect. Or looking for easy to spot things that can point to bigger problems, but require looking deeper to confirm.
I can't understand why anyone would have that line of thought, but at least it seems to explain your mental block.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
You can additionally use a VCS to check stuff and see if people are writing the tests first.
You can't if they're in the same commit.
-
@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™):
You can additionally use a VCS to check stuff and see if people are writing the tests first.
You can't if they're in the same commit.
Can you think of a way to solve that? LOL, this is like talking to a kid who can't possibly think more than one step ahead.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@LaoC 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™):
@LaoC 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™):
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
TDD is like the Catholic catechism that (yeah, simplifying a bit here for the sake of it) says you're supposed to go into marriage as a virgin and then have sex in order to procreate. A bit stupid but there are people who say it's got something going for it. CI is basically checking whether people have sex after marriage, and you're proposing that as a way to verify and facilitate marriages in accordance with the Catholic catechism.
In fact I am not.
As I already said, CI will catch out the people who don't
write any testshave sex. Or who don't bother tomake their tests passprocreate. That is an important part ofTDDthe catechism as I understand it. Not sufficient, but certainly necessary.Yes, many people think marriage should usually involve sex. What sets the Catholics (and a few others) apart is the virginity-before bit.
Yes, and?
You should ask a Catholic whether they think a check for sex after marriage can be thought of as a way to facilitate marriage according to their faith. The result will surprise you™.
You can additionally use a VCS to check stuff and see if people are writing the tests first.
How is this difficult to understand?
CI facilitates TDD because you can use some other thing to manually check for TDD compliant procedures that upset the CI system. OK, that's easy to understand, it's just dumb.
Yes, what you said sounds dumb and also demonstrates that you didn't understand what I said. Unless you believe that someone not writing passing tests could be following TDD.
Someone who doesn't have sex after marriage is certainly not married according to Catholicism. That's not quite the point of the catechism though.
-
@LaoC 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™):
@LaoC 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™):
@LaoC 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™):
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
TDD is like the Catholic catechism that (yeah, simplifying a bit here for the sake of it) says you're supposed to go into marriage as a virgin and then have sex in order to procreate. A bit stupid but there are people who say it's got something going for it. CI is basically checking whether people have sex after marriage, and you're proposing that as a way to verify and facilitate marriages in accordance with the Catholic catechism.
In fact I am not.
As I already said, CI will catch out the people who don't
write any testshave sex. Or who don't bother tomake their tests passprocreate. That is an important part ofTDDthe catechism as I understand it. Not sufficient, but certainly necessary.Yes, many people think marriage should usually involve sex. What sets the Catholics (and a few others) apart is the virginity-before bit.
Yes, and?
You should ask a Catholic whether they think a check for sex after marriage can be thought of as a way to facilitate marriage according to their faith. The result will surprise you™.
I doubt that it would. I'm amused that you think you are making an argument against anything I said.
You can additionally use a VCS to check stuff and see if people are writing the tests first.
How is this difficult to understand?
CI facilitates TDD because you can use some other thing to manually check for TDD compliant procedures that upset the CI system. OK, that's easy to understand, it's just dumb.
Yes, what you said sounds dumb and also demonstrates that you didn't understand what I said. Unless you believe that someone not writing passing tests could be following TDD.
Someone who doesn't have sex after marriage is certainly not married according to Catholicism. That's not quite the point of the catechism though.
I see you're fully committed to this poor analogy. Let me know if you ever come up with a relevant argument.
-
@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™):
@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™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
Such as?
@HardwareGeek 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™):
I guess when you said "sure", you actually meant no
Congratulations on your discovery of sarcasm.
I mean...it was snarky, but I was actually agreeing there. And then I pointed out that you'd been ignoring the answers you were asking for, so perhaps you can understand, once again, my frustration with your intentional anti-communication.
Assuming I was actuallly ignoring anything, yes, it's understandable. But that assumption is wrong. I explained over and over again why "checking if you have tests at all" does not help in the process of TDD itself, and therefore doing TDD without it is no different from doing TDD with it. And so calling those monitoring tools "TDD tools" is wrong, and calling using them "tool-assisted TDD“ is wrong too. You were ignoring that way more than I was ignoring anything you said.
I asked you about this before and I don't recall getting an anwser.
Oh look, someone doesn't read other people's post!
Are you saying there are no tests or something?
I literally just answered this very question 5 posts ago. All those quips about me not reading what you say really look like psychological projection now.
OK, I guess it was too far apart from when I asked that.
IT WAS LITERALLY A DIRECT IMMEDIATE REPLY TO YOUR QUESTION, I EVEN QUOTED IT ARGHHHHHHHHHHHHHHHHHH
Also you were back apparently denying the existence of tests.
No I wasn't, and if you think I was, you can't read.
How else could this be interpreted?
"Test count monitoring is way too high-level, coarse-grained and unspecific to be a useful tool in checking whether TDD process is being followed." For example.
I see. So you're firmly in the camp of the good is the enemy of the perfect.
No again. I'm firmly in a camp of "if a tool coincidentally has a second-order side effect of, among other things, making it a tiny bit more likely to catch the most egregious cases of not using TDD, then it's not a TDD tool, and using it doesn't make your TDD a tool-assisted TDD."
I can't understand why anyone would have that line of thought
Maybe because no one has and you're just imagining things? Instead of, you know, actually reading my posts? Something you repeatedly accuse me of not doing?
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@LaoC 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™):
@LaoC 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™):
@LaoC 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™):
Definitely not by looking at number of tests or whether they pass. From CI's point of view, or from manager's spreadsheet's point of view, there's zero perceivable difference between writing tests together with implementation, and writing tests post factum. If you write tests post factum, even if it's the code you wrote 20 minutes ago, that's not TDD. But your tools won't be able to tell a difference.
Except how do you even know you have tests? You've missed the point entirely.
TDD is like the Catholic catechism that (yeah, simplifying a bit here for the sake of it) says you're supposed to go into marriage as a virgin and then have sex in order to procreate. A bit stupid but there are people who say it's got something going for it. CI is basically checking whether people have sex after marriage, and you're proposing that as a way to verify and facilitate marriages in accordance with the Catholic catechism.
In fact I am not.
As I already said, CI will catch out the people who don't
write any testshave sex. Or who don't bother tomake their tests passprocreate. That is an important part ofTDDthe catechism as I understand it. Not sufficient, but certainly necessary.Yes, many people think marriage should usually involve sex. What sets the Catholics (and a few others) apart is the virginity-before bit.
Yes, and?
You should ask a Catholic whether they think a check for sex after marriage can be thought of as a way to facilitate marriage according to their faith. The result will surprise you™.
I doubt that it would.
No doubt you do.
You can additionally use a VCS to check stuff and see if people are writing the tests first.
How is this difficult to understand?
CI facilitates TDD because you can use some other thing to manually check for TDD compliant procedures that upset the CI system. OK, that's easy to understand, it's just dumb.
Yes, what you said sounds dumb and also demonstrates that you didn't understand what I said. Unless you believe that someone not writing passing tests could be following TDD.
Someone who doesn't have sex after marriage is certainly not married according to Catholicism. That's not quite the point of the catechism though.
I see you're fully committed to this poor analogy. Let me know if you ever come up with a relevant argument.
Seriously? ICBA.
-
@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™):
@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™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
Such as?
@HardwareGeek 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™):
I guess when you said "sure", you actually meant no
Congratulations on your discovery of sarcasm.
I mean...it was snarky, but I was actually agreeing there. And then I pointed out that you'd been ignoring the answers you were asking for, so perhaps you can understand, once again, my frustration with your intentional anti-communication.
Assuming I was actuallly ignoring anything, yes, it's understandable. But that assumption is wrong. I explained over and over again why "checking if you have tests at all" does not help in the process of TDD itself, and therefore doing TDD without it is no different from doing TDD with it. And so calling those monitoring tools "TDD tools" is wrong, and calling using them "tool-assisted TDD“ is wrong too. You were ignoring that way more than I was ignoring anything you said.
I asked you about this before and I don't recall getting an anwser.
Oh look, someone doesn't read other people's post!
Are you saying there are no tests or something?
I literally just answered this very question 5 posts ago. All those quips about me not reading what you say really look like psychological projection now.
OK, I guess it was too far apart from when I asked that.
IT WAS LITERALLY A DIRECT IMMEDIATE REPLY TO YOUR QUESTION, I EVEN QUOTED IT ARGHHHHHHHHHHHHHHHHHH
Also you were back apparently denying the existence of tests.
No I wasn't, and if you think I was, you can't read.
You explained yourself, and it turned out to be really dumb.
How else could this be interpreted?
"Test count monitoring is way too high-level, coarse-grained and unspecific to be a useful tool in checking whether TDD process is being followed." For example.
I see. So you're firmly in the camp of the good is the enemy of the perfect.
No again. I'm firmly in a camp of "if a tool coincidentally has a second-order side effect of, among other things, making it a tiny bit more likely to catch the most egregious cases of not using TDD, then it's not a TDD tool, and using it doesn't make your TDD a tool-assisted TDD."
LOL. "Tool that helps doesn't help." Yes, a very good position to maintian.
I can't understand why anyone would have that line of thought
Maybe because no one has and you're just imagining things? Instead of, you know, actually reading my posts? Something you repeatedly accuse me of not doing?
Yeah, it's weird. I read your stuff and you seem to read mine and yet you never address the things I'm saying.
-
@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™):
@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™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla except for all those times you "sarcastically" wrote the opposite of what you meant and talked in nothing but rhetorical questions...
Such as?
@HardwareGeek 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™):
I guess when you said "sure", you actually meant no
Congratulations on your discovery of sarcasm.
I mean...it was snarky, but I was actually agreeing there. And then I pointed out that you'd been ignoring the answers you were asking for, so perhaps you can understand, once again, my frustration with your intentional anti-communication.
Assuming I was actuallly ignoring anything, yes, it's understandable. But that assumption is wrong. I explained over and over again why "checking if you have tests at all" does not help in the process of TDD itself, and therefore doing TDD without it is no different from doing TDD with it. And so calling those monitoring tools "TDD tools" is wrong, and calling using them "tool-assisted TDD“ is wrong too. You were ignoring that way more than I was ignoring anything you said.
I asked you about this before and I don't recall getting an anwser.
Oh look, someone doesn't read other people's post!
Are you saying there are no tests or something?
I literally just answered this very question 5 posts ago. All those quips about me not reading what you say really look like psychological projection now.
OK, I guess it was too far apart from when I asked that.
IT WAS LITERALLY A DIRECT IMMEDIATE REPLY TO YOUR QUESTION, I EVEN QUOTED IT ARGHHHHHHHHHHHHHHHHHH
Also you were back apparently denying the existence of tests.
No I wasn't, and if you think I was, you can't read.
How else could this be interpreted?
"Test count monitoring is way too high-level, coarse-grained and unspecific to be a useful tool in checking whether TDD process is being followed." For example.
I see. So you're firmly in the camp of the good is the enemy of the perfect.
No again. I'm firmly in a camp of "if a tool coincidentally has a second-order side effect of, among other things, making it a tiny bit more likely to catch the most egregious cases of not using TDD, then it's not a TDD tool, and using it doesn't make your TDD a tool-assisted TDD."
I can't understand why anyone would have that line of thought
Maybe because no one has and you're just imagining things? Instead of, you know, actually reading my posts? Something you repeatedly accuse me of not doing?
Oh. I would also add that you still seem to be hyperfocused on the activities of an individual and refusing to consider what it would take for an organization to do this stuff well, which has been what I've been talking about the whole time. Because that was the claim made that you were replying to.
-
The only automated tooling I can think of that would enforce strict TDD rather than the weaker requirement for high test coverage would be to have checkin requirements, even on local commits, that enforced each commit either introducing new failing tests, or fixing existing failing tests. That would be an incredibly annoying workflow, I imagine even the most zealous TDD fans are mainly going to want to commit test and implementation together most of the time