I have an enum in Kotlin with "util" associated functions as part of a Companion object and marked as #JVMStatic to be able to access them from java code as static methods.
I would like to be able to have some unit testing for that functions.
Is the approach I took bad for testing and what would be the proper approach for Kotlin and testing?
Related
In an attempt to make my code friendly for unit testing, it seems wise to utilize depenency injection. This requires that any dependent class must implement an interface with the exact same set of methods.
I also see advice saying that I shouldn't have an interface for every class, but I don't see how I could possibly follow both pieces of advice. If I want unit testing, every single useful class must adhere to an interface.
Proof: Suppose there exists a class that does not implement any interfaces. If I am able to unit test my entire program, then no other code depends on this class. Therefore this class is useless and might as well be deleted.
Is there something I am misunderstanding? Is there a way to unit test without copy/pasting all of my classes into equivalently structured interfaces?
In order to write effective tests, you do need seams in your code (a place that let's you break your dependencies apart) to allow you to control any dependencies in your code. Interfaces are possibly the most obvious way to do this, but you can use other techniques such as wrapping your dependency in a method on your class under test and declaring that method as protected virtual (c#) and overriding the class for your unit tests. There is a great series of videos on YouTube around TDD that deal with design decisions when doing TDD. Search for "is TDD dead".
When unit testing, you usually just want to mock classes that make external calls (be it a database query or hitting an API). Consequently, you need to have an interface for these classes. However, a lot of times you may have random DTOs or utility classes that do small simple things and don't need to be mocked.
Some languages have tools that let you mock classes without writing a corresponding interface; for instance, Python allows patching arbitrary classes in test code, and the Mockito library for Java can generate a mock object from any class.
There is a school of thought that says when writing unit tests, only the "leaves", i.e. classes and methods which don't invoke other classes within the application, should be unit tested in isolation, and classes that are involved in orchestrating the behavior of other classes should be tested at the acceptance or integration level. This style of testing avoids writing unit tests that depend on mocking most of the classes in your application, and so avoids the need to write interfaces. Martin Fowler's article on mocks covers some of the differences between different styles of testing regarding mocks.
I have a class X with all static methods. And an app A to test the behavior of this class.
I have separate unit tests for both.
Note: I have to strictly adhere to writing separate unit tests for both.
Suppressing the static initialization for the class A is affecting unit tests of the class X for which I'm doing mockstatic in class A.
I'm not sure of the scope of #SuppressStaticInitializationFor.
That is the problem when turning to PowerMock to fix problems introduced by unwise usage of static. Keep in mind: static is an abnormality within good OO design - as it breaks (easy) unit testing, polymorphism, and leads to direct coupling of your classes!
So my advise here: simply avoid using static in a way that leads you to ask for PowerMock in order to do unit testing. In other words: instead of using PowerMock, learn how to create testable code (you can start here)) and then create production code that can be tested with Mockito or EasyMock ... without any super Powers needed.
If you can't do that: at the very minimum, make sure that you never create static init code that breaks your unit test environment. It is a fair request to your development team to come up with production classes that can at least be loaded by JUnit tests.
I have existing code which uses mockito to mock the public interface in class.
I am adding some static methods in same class so planing to use powermock.
Does powermock allow to keep the existing functionality of mockito ?
From PowerMock's Getting Started Page:
PowerMock consists of two extension API's. One for EasyMock and one for Mockito. To use PowerMock you need to depend on one of these API's as well as a test framework. Currently PowerMock supports JUnit and TestNG.
If you are using PowerMock and its Mockito extension API, you will also depend on Mockito—and these two tools interact just fine. Use pure Mockito wherever possible, and use PowerMock to handle legacy code cases and other places where you need to mock final classes, final/static methods, and so forth.
I have a library which is quite large but only exposes a very tiny API to make it easy to use and learn for new users. I would like to keep my library this way, but I also want to ensure that I have as much unit test coverage as possible, I would like to be able to directly unit test all of my classes but so far as I can tell I can only unit test the public API of the library.
I can, of course, write unit tests to fully test the public methods which will effectively indirectly test all of the underlying private classes, but if a test fails it could mean a lot of digging around in the private code to find out where something went wrong, rather than having unit tests for each individual private class so when something goes wrong it's immediately apparent what went wrong and where.
Is there a design pattern to help with this situation or a way for unit testing to be written for private dart classes and methods?
If you move your private classes into a separate library in the same application then you can make them public and test them. You would then import that library in your current library and not export it (so the user of your library still can't use your other classes as long as he doesn't import that other library himself).
I am trying to set up some unit tests for an existing c++ project.
Here's the setup:
I have chosen Google Mock, which includes Google Test. I have added another project (called Tests) to the Visual Studio Solution. The units to test are in another project called Main. The plan is to add each cpp file that I want to test to the Tests project. The Tests project has access to all header files from Main.
I have added one cpp file to the Tests project, and it compiles, but comes up with linker errors. Most are because of a class derived from COleDateTime, called CTimeValue. The unit under test has methods with pass-by-value CTimeValue parameters and also declares some CTimeValue attributes.
I want to test the UUT in isolation, and use mocks and fakes for all dependencies. I don't see how to do it with CTimeValue. It is used as a value, contains no virtual methods, but is still quite complex and would deserve a seperate unit test.
CTimeValue is only one of many classes that is like this in the project. How can I isolate the testing of classes that use these user-defined types?
Cheers, Felix
Sometimes one can not simply mock things. In that case what you can do is have a comprehensive test for the class in question (CTimeValue) and make sure you run the tests for that class as a subsuite in your other test.
Using a mock object you only need to add the method signatures that your UUT uses so maybe you can create a mock using google mock. Of course you will need a separate test suite for the CTimeValue class, and if you have that then it is probably better to link in the actual object. You need to decide if it is worth the effort to create an interface class to create the mock from.
Mocks are most suitable for working with objects that provide services for each other, the expectations on the mocks describe their relationships. There's not much point in mocking value objects.