> Isn't this just a case of 'how do we name things'? > > Assuming that we adopt your definition of a Unit Test ... > > Given a specific test, do we spend time to catagorize it > as a 'Unit Test' or some other type of test? What is the > point of making such a distinction? > > If a unit of code, for example a function, is given one or > more tests that attempt to prove that its logic is > working, why is it important that we define these tests as > 'Unit' or not? For example, a function that reads an > entire text file into a RAM buffer may have one or more > tests written to show that that is exactly what is > achieves when run. Why split hairs about calling them Unit > Tests or not? They are useful and important tests, whether > or not they fit your Unit test definition. > > How would my coding or testing behaviour change by calling > some tests "Unit Tests" and other tests something else? > > These are not rhetorical questions as I honestly don't > know the answers and would like to improve my knowlege and > practice of programming.
I'm glad you brought it up. It is a matter of how we name things, but also what we motivate ourselves to do. When I first ran into this problem of database/IO bound tests, I sat with a team and they told me that they had a couple hundred UTs. I looked and them and said "well, these over here look unit-ish, but those over there, we shouldn't count those." I formulated a few rules with that first team and they agreed to try using them. They did end up writing tests that touched the database but only a few of them, and as an internal metric they decided to pay attention only to the number of UTs satisfied the "rules." By keeping those rules in mind and acting on them they ended up with far more decoupled software.
One thing that is interesting about this thread is that many are irked by the def of UTs that I laid out. The thing is, I'm not trying to change the def in the industry. But locally, with some teams, it's a great way to focus. Anyone who doesn't want to do that, or call them that, it's fine with me. It's just naming after all. I view rules as a local matter. Teams can create whatever rules they want or name things whatever way they wish to.. but it's great not to underestimate the power of using rules like that to raise the bar. The ones I outlined may be good for your team or not. Drop some or add some, but regardless, raise the bar.
Flat View: This topic has 50 replies
on 51 pages
[
«
|
151617181920212223
|
»
]
Previous Topic
