| tags |
|---|
testing, unittest |
https://twitter.com/jbrains/status/1450572234842591236
"Unit test": a test for a unit.
"Unit": any part of a software system that can be independently inspected. By "independently inspected", I mean "able to be inspected without running other parts of the system".
Many of us conflate "unit" with "small" and I wonder why that should be.
I'm not claiming that "unit" is the best word, but inasmuch as we use it, we ought to clarify what we mean by it.
I don't think units need to be small. I find it useful when units are generally smaller, but I don't understand why units need to be small. Why do you believe that it's necessary for units to be small?
Kevin Rutherford:
I try to get teams to drop the word "unit". I talk about "fast tests" and "slow tests" instead, emphasising their roles in our feedback loops.
Michael Feathers
Tests define units. A talk by @ICooper triggered my thinking on this. https://blogs.itemis.com/en/unit-tests-are-tests-of-modularity
Unit tests:
- work against some sort of interface,
- give coverage with a small number of cases and
- don’t do an incredible amount of setup to reach obscure conditions.
They document a simple understandable thing – a unit. Unit tests are tests of modularity: if it’s difficult to write a test for a code change, your code could be more modular, and the modules should be relatively small.
Ferdinando Santacroce:
Sasa Juric:
- test behavior, not implementation level details
- test units of behavior, not units of code
@RaphaDeveloper:
I Like to think in Unit as a Scenario of a Use Case. That strategy enable me to write tests attached to behavior and not to implementation details so I can refactor the details inside my code whithout break my tests. I usually test an method that is the entry point of a Use Case.
FranckGuillaud:
@christianhujer:
And as I always say, time to ditch that definition. It's not helpful anymore. It was a great definition before Moore's law enabled modify-build-test feedback loops that only take seconds, and before we learned about the importance of continuous refactoring.