I didn't quite understand why using verifications to check if your implementation does some calls is a bad thing, can you elaborate on it?
So first, it's not inherently bad. It depends on how and how often you use it.
Let me give you an example:
void methodA(int someInt, int someOtherInt) {
objA.foo(someInt);
objB.bar(someOtherInt);
}
When you write tests, that verifies calling both methods, especially in a specific order, you duplicate the implementation in your tests. Test should focus on checking results based on some input. That's what I means with "functional style". So I would always try not to have any such methods like the one above that only have side effects. Rather I would write methods like:
int methodA(int someInt) {
int foo = objA.foo(someInt);
int bar = objB.bar(someOtherInt);
return foo + bar;
}
Now you can simply write a test for example
assertThat(instance.methodA(1 + 2)).isEqualTo(3);
When you figure out, that you can simplify your method by writing...
int methodA(int someInt, int someOtherInt) {
return someInt + someOtherInt;
}
the test ist still green, because you tested the result, not the internal behaviour.
That's why TDD is so important. It forces you to design all of your classes, methods, functions in a way that they can easily be tested by simply putting some values in and expecting something out.
There are obviously exceptions to this "rule", but there should be a very good reason.
Side effects should only happen at the very boundary of the application, e.g. REST on one side and a DB on the other. All code in the middle can be written in a functional style without any side effects.
Yes. My team and I are working with their product for .NET and we are satisfied. I wanted to hear from other people who use their product...I guess I'll just keep looking :)
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.
So first, it's not inherently bad. It depends on how and how often you use it.
Let me give you an example:
When you write tests, that verifies calling both methods, especially in a specific order, you duplicate the implementation in your tests. Test should focus on checking results based on some input. That's what I means with "functional style". So I would always try not to have any such methods like the one above that only have side effects. Rather I would write methods like:
Now you can simply write a test for example
When you figure out, that you can simplify your method by writing...
the test ist still green, because you tested the result, not the internal behaviour.
That's why TDD is so important. It forces you to design all of your classes, methods, functions in a way that they can easily be tested by simply putting some values in and expecting something out.
There are obviously exceptions to this "rule", but there should be a very good reason.
Side effects should only happen at the very boundary of the application, e.g. REST on one side and a DB on the other. All code in the middle can be written in a functional style without any side effects.
For Java: Mockito or Spring Test, see my other article for some examples on how to do integration tests: dev.to/stealthmusic/modern-java-de...
Thanks a lot!
Have you heard about Typemock by any chance?
Nope, not yet. I just looked it up, it's .NET and C/C++, right?
Yes. My team and I are working with their product for .NET and we are satisfied. I wanted to hear from other people who use their product...I guess I'll just keep looking :)