I am currently working on introducing continuous integration and switching to git, and as part of that, we must also better structure our tests.
We have agreed on splitting the tests in “integration” and “unit” – however he doesn’t seem to agree that touching the database is also integration testing.
The code is horrible, everything is coupled to the database, it’s hard to mock and stub, and I want to move it on the long term towards a better modularisation and testability.
Getting him to accept and use the proper naming is critical in future arguments.
So how to convince him that every test which touches the database is also integration testing?
At the moment he thinks that exec()-ing an external program or using an external interface (e.g. via SOAP) is an integration test.
He also thinks that everything which is slow belongs to integration testing, while he’s in love with his “lightning fast database”.
10
I think that when you are dealing with people who think they know best, or you are just in a position where they don’t think they should be listening to you, the best way is question their ways.
He is probably the type that believes that he should be the one making the decisions (independently of whether or not he is the most qualified). And just telling him your view is not really helpful. You have to plant a seed in him that can help him make a new, better decision.
Instead of telling your boss how you should be structuring your tests, you should question his ways – “why do you believe that tests hitting the database are unit tests when every well respected resource says that unit tests should not touch the database?”, “Shouldn’t unit tests be independent? How can they be when they touch a shared database? Shouldn’t they be able to run in parallel?”
You say that he is quite inconsistent with himself, which I think you should focus on. “I don’t understand, when you say that integration tests are … but then you say that … is not/also an integration test?”
If you just tell him, “unit tests should not touch the database”, you are indirectly just saying to him, “you are wrong, I am right”, and he will start being defensive. If you question his ways, you are forcing him to think.
It is important that you phrase your questions in a way where you really try to understand his point of view. If not, your questions will be just a slightly modified version of dictating your own point of view, and the debate quickly becomes tiring for both. And maybe he has a valid point somewhere that you should also understand.
Disclaimer: I have now tried to analyze your boss without ever actually having met him, which is of course impossible. But the scenario you describe is consistent with a pattern I have seen before.
5
I think you are going about this the wrong way. Don’t get into an argument over the definitions of words, that’s not useful. Trying to argue for changes in development methodology by arguing over the definition of an integration tests, is like try to square a circle by changing the definition of a square.
Instead, argue for what you actually want to change. Do you want the ability to test functionality without hitting the database? Then present a case why that would be useful. Do you want your tests to run faster? Then show how it can be done. Do you want cleaner code by not mixing database logic everywhere? Show the benefits.
Appealing to a definition that says that “database access does not belong in integration tests” is just cargo culting. Instead, gives reasons why we should avoid database access in the primary test suite. I think you’ll find the definitions follow.
2
Challenging someone who thinks they know best is always a problem. You have run into someone who believes “everything is a unit test,” and that kind of miscategorization is hard to address.
Provide him with a scale of interactions, that has some hierarchy to it. Ask him to draw lines where he wants to define things. For instance.
- Single method/procedure, no side effects; returns zero or more values.
- Single method/procedure, side effects affect the class it’s in only; returns zero or more values.
- Single method/procedure, no side effects but uses an imported library.
- Single method/procedure, no side effects but uses other classes/methods that are part of the code under test.
- Single method/procedure, no side effects, but reads the database using JDBC library.
… and so on.
At what point does he draw the lines for “Unit”, “Functional” and “Integration” tests?
Here is a similar scale: 1) single class, 2) single class plus a couple of jars, 3) single class plus JDBC/H2 in-memory database, 4) single class plus JDBC/MySQL on same machine, 5) single class plus JDBC/Oracle on separate database machine.
Another scale: 1) sub-millisecond test time, 2) sub-tenth of a second test time, 3) sub-second test time.
I am guessing that there will be plenty of other factors that are coming into play that you might not have considered. They are probably not technical. Eg, time, effort, understandability, simplicity, upcoming future work, previous decisions already made, etc.
There is obviously a lot of conflict around the database. You need to take a step back here, he’s obviously very proud of it, and knocking it isn’t going to help your case. If it’s fast, that’s a good thing.
It could well be that your points are quite valid, and s/he might be pushing back because of the way you are suggesting them.
Also, chillax, remember that nobody has ever died because of the mockability of an application 🙂
3