For whatever reason, I've never bought into TDD philosophy, although I'm glad it works for some people, and won't begrudge them for following it. I do test, quite a lot, actually, but my philosophy is a bit different: I write my tests to follow the abstraction layers of my application.
This means I'm probably testing important features four different ways, but if goal X works through layers A and B, but fails through layer C, then I know the problem is C. Technically, some TDD expert could go through and classify my tests as "integration" or "unit," but I think that overcomplicates things, and leaves me more vulnerable to compartmentalization. I just think, "if A does X, Y, Z (in any manner), I'll test X, Y, Z through A's interface. Then, if B does W, X, Y, Z, test those through B's interface." I ensure that what is supposed to work works, and what isn't supposed to work fails.
That also means that my current test suite takes about four seconds to run on one current Python project...but I also have caught things that typical unit testing would have probably missed. By time I'm done, I forsee that being somewhere about a ~30 second runtime when the project is done, but I come from C++, where I spend that much time or more just waiting for code to compile. I'm patient, and don't tend to skip things that take time.
Side note: my main beef with TDD per se is "write the tests, then the code," which is the opposite of how I'm hardwired to think. I figure out what I want to happen, and refine it as I work. I write the code and tests in tandem with one another, modifying both as my design changes. (These days, that takes place in a split editor.) That doesn't work for everyone, but it's served me well for many years.
In my experience a test first approach produces better code and tests -there will be a few words about it in the next posts of the series-, but this does not have to work the same way for all of us. Not following TDD is a totally fair approach as long as your code ends up well tested.
However, TDD and the type of test you end up writing and running are not correlated. The type of a test, at least in the sense pointed in the post, is related to the type of interaction tested, no matter you wrote it before, after or along with the implementation.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For whatever reason, I've never bought into TDD philosophy, although I'm glad it works for some people, and won't begrudge them for following it. I do test, quite a lot, actually, but my philosophy is a bit different: I write my tests to follow the abstraction layers of my application.
This means I'm probably testing important features four different ways, but if goal X works through layers A and B, but fails through layer C, then I know the problem is C. Technically, some TDD expert could go through and classify my tests as "integration" or "unit," but I think that overcomplicates things, and leaves me more vulnerable to compartmentalization. I just think, "if A does X, Y, Z (in any manner), I'll test X, Y, Z through A's interface. Then, if B does W, X, Y, Z, test those through B's interface." I ensure that what is supposed to work works, and what isn't supposed to work fails.
That also means that my current test suite takes about four seconds to run on one current Python project...but I also have caught things that typical unit testing would have probably missed. By time I'm done, I forsee that being somewhere about a ~30 second runtime when the project is done, but I come from C++, where I spend that much time or more just waiting for code to compile. I'm patient, and don't tend to skip things that take time.
Side note: my main beef with TDD per se is "write the tests, then the code," which is the opposite of how I'm hardwired to think. I figure out what I want to happen, and refine it as I work. I write the code and tests in tandem with one another, modifying both as my design changes. (These days, that takes place in a split editor.) That doesn't work for everyone, but it's served me well for many years.
In my experience a test first approach produces better code and tests -there will be a few words about it in the next posts of the series-, but this does not have to work the same way for all of us. Not following TDD is a totally fair approach as long as your code ends up well tested.
However, TDD and the type of test you end up writing and running are not correlated. The type of a test, at least in the sense pointed in the post, is related to the type of interaction tested, no matter you wrote it before, after or along with the implementation.