4

This questions looks weird or may be pointless at all. Recently, I was reviewing some code in java language where the developer used one of the methods from a unit testing library "org.easytesting". Example: He was using a method "Strings.isNullOrEmpty" of "Strings" class from this library to verify the non-nullability of some values and was using other classes/methods at other places in the code.

I know a library is developed to make our life easier(basic principles of Java) and can be used anywhere/everywhere, but is there a recommendation about using a unit test library in live development code ? I know using it won't led to a compatibility issue because unit test cases are executed always.

I searched at many places may be I'm missing a good word to search.

Aman
  • 124
  • 1
  • 8
  • 2
    I don't see anything wrong with this per se. After all, you might use _non_ unit testing libraries inside your unit test project, so why would the reverse not be acceptable? That being said, I might avoid using a unit test library, if I could find the same functionality elsewhere. – Tim Biegeleisen Oct 30 '18 at 06:30
  • Yes, as you said, we often use non-unit testing libraries while writing unit test cases. @TimBiegeleisen Would you mind explaining this statement "I might avoid using a unit test library, if I could find the same functionality elsewhere", any strong point to favor that ? – Aman Oct 30 '18 at 06:37
  • I wouldn't pull in *any* library simply to check the nullity of a string. – Andy Turner Oct 30 '18 at 07:08
  • @AndyTurner Yes, one can directly do a null comparison, this question is more about a general recommendation. – Aman Oct 30 '18 at 07:12
  • 1
    I like this question. Yes, there is nothing forbiding it. However, it somehow feels wrong as pointed out by a collegue when we talked about a dependency to findbugs just to have @Nonnull anotations. – Burkhard Oct 30 '18 at 08:25
  • 1
    @Burkhard You're right, many developers just look for a solution for a particular issue and if they find it with a simple annotation , they don't mind including a huge library for it. :D – Aman Oct 30 '18 at 10:13
  • Correct me if I am wrong, but [Strings.isNullOrEmpty](https://google.github.io/guava/releases/23.0/api/docs/com/google/common/base/Strings.html) is from Guava. And that lib is not specifically dedicated to unit tests. – Benoit Oct 31 '18 at 08:45
  • 1
    @Benoit - There are many libraries which provide the utility methods/classes for operations on Strings. e.g. immutable, elastic search, couch base, etc. All the aforementioned libraries have the Strings class and provide "isNullOrEmpty" method. Apart from these libraries, there are many unit test libraries like easy testing, fest-assert, etc which provide this method – Aman Oct 31 '18 at 10:01

3 Answers3

1

It could be argued that a unit-test library is just a library, but I don't see it like this.

First, the purpose of a unit-test library is to be used in code that is not production code. Which means, that certain quality criteria relevant for production code might not be met. For example, if there is a bug in a unit-test library it is annoying, but normally does not harm the production code. Or, performance may not be quite as relevant, thread safety and so on. I don't want to say that the popular unit-testing frameworks are of a bad quality. But, the developers of these libraries have all the right in the world to take design decisions based on the assumption that their code will not be part of production code.

Secondly, using a library should be done in accordance to the philosophy of the respective library. For example, if you use a certain gui library, this brings implications on the way event handling is done in your application. And, unit-testing frameworks come under the assumption that the framework is in control of the executable (from the test runner). Therefore, all functions from that library may depend on the test runner being set up and running. If some function from the library does not have this dependency, that is an implementation detail which may change with a new version of the library.

Finally, code should communicate intent. That includes includes (pun intended). It was not the intent of the developer to write unit-testing code, but that would be what the inclusion of a unit-testing library would communicate.

Dirk Herrmann
  • 5,550
  • 1
  • 21
  • 47
1

Considering that there are other, production-oriented libraries out there which check if a string is empty or null, any use of the testing framework's method should be treated as a strong code smell and identified in code reviews.

In the future, this testing library may introduce a change in other parts which make running it in production either prohibitively expensive or insecure, as the code running through this empty or null check could be leveraged as an area of attack. Worse, if your team wants to pivot away from this testing framework, you now have to change production code which many teams would be reluctant to do if all they're doing is changing test dependencies.

Makoto
  • 104,088
  • 27
  • 192
  • 230
0

Without looking specifically at test libraries, here's an answer to this more general question:

Should you use the general-programming utility classes that are provided by any framework or library? (For example, should you use the StringUtils/CollectionUtils/etc provided by a web/UI/logging/ORM/... framework).

The arguments by the other answers are still mostly valid even in this more general case. Here are some more:

  • These utilities have been developed specifically for use by the framework. They likely only contain very specific methods with narrow use cases (those that are actually required by the framework) and nothing more. They might be optimized for specific internal behavior of the framework and not for general purposes.
  • Framework developers may introduce breaking changes without much thought, since they don't expect many users outside of their framework.
  • It would be alarming to see imports from e.g. a UI library in your back end code, it looks like code smell.
  • In modular projects, you wouldn't want to introduce additional dependencies to the framework's utilities (again, a dependency to an UI framework from you back end modules is code smell). It would also add a bunch of unnecessary transitive dependencies that may aren't even compatible with other dependencies.

So I would say generally you shouldn't use the utilities of frameworks, except in those places where you are actually working with those frameworks. But even then you should consider using Apache Commons or Guava etc. for consistency.

Now you could also replace the terms UI and back end with test and production in the last two points. Test frameworks are also special in the sense that you usually don't include them as run-time dependency. So you would need to change the scope of the test dependencies to make them available at run-time. You should avoid this for the reasons given in the last point.

kapex
  • 28,903
  • 6
  • 107
  • 121