I'm wondering if it is possible to create a Test Object to be shared between multiple JUnit Classes. So I don't have to copy & paste Fixtures for multiple classes.
I have a translator object that stores mapping between language A and B. This is a common object that I used for Processor and Translation Classes.
Right now I have a Test Fixture at JUnit Test Classes for both ProcessorTest and TranslationTest Classes. E.g.
#Before
public void setUp()
{
translator.add("hi","hola");
translator.add("bye","adiós");
}
Thanks.
You can put the fixtures into an abstract class, and make your test classes extend this class.
Or create an implementation of a TestRule and add them to each class.
You may also be able to just have a static method somewhere that creates and sets up the translator object, and call this method within the test class.
Related
I'm mainly a Java developer and wonder about structure when writing unit test in kotlin,
Assuming there's no package-private in kotlin
private to restrict visibility to the file
internal to restrict visibility to the module
How can I open class only to test class ?
Must I write test inside kotlin class or open class to all module (internal)?
What's the kotlin way to open method for unit test only?
EDIT
Found similar question/request in kotlin discuss by #bentolor:
How am I supposed to do unit / whitebox testing properly? I want to write test code which tests class-internal functionality which I do not want to expose to other classes except my test class at all.
The package protected visibility is an excellent way to achieve this. Whereas Kotlin now requires me to make these methods effectively public and litter the visible API of my component all-over the project be able to test them.
In my view internal is more or less public as it has a much larger scope. Most projects have sth. around 1 - 5 “modules” in the Kotlin sense.
Really strongly asking/advocating for package-local visibility here.
Formally it is not possible to do this honestly on JVM, because class couldn't be open for subset of possible interiters.
However it can be partially done by the following trick:
open class SomeClass internal constructor(val configurableParameter: Int) {
companion object {
private const val defaultInput = 123
fun create() = SomeClass(defaultInput)
}
}
The constructor of this class can be called only from the same module (or from tests). And class is public, so anyone can use it. However from external modules you have only two ways of the class construction: companion object or reflection.
And finally you couldn't inherit from this class at any other modules, because constructor is internal.
For Android developers only, there's AndroidX VisibleForTesting annotation
Denotes that the class, method or field has its visibility relaxed, so that it is more widely visible than otherwise necessary to make code testable
I am just starting with mocking using googlemock for a C++ project. In my case, my class to be tested observes a file that is written to, and whenever a minimal amount of new data has been written, it starts doing some work.
What I need is a mock class for the process writing to the file. As far as I understand things, I need to completely implement this "writing to file" functionality in form of (for googlemock) a virtual class from which a mock class is derived? The mock wrapper is finally used for testing and evaluation purposes, right?
Thanks for help!
Mocks, in google mock terms, are objects used to validate that your code under test performs certain operations on them.
What you describe is not a mock, but a utility class that triggers your code under test operations.
What does your class do when it detects that the file it observes is written to? If, for instance, it performs a call to another object, then you could use a mock object to check that it gets called with the right parameters, e.g. the new bulk of data written to the file.
I am assuming that an object of your "observer" class is notified
that minimal amount of data has been written by an object of
the "writter" class. In that case, you need to implement an abstract
class that represents an interface for your "writter" class, and have
your real "writter" class inherit from it and override its virtual functions.
Also, have your mock "writter" class implementation inherit from this interface and
and create mock implementations using MOCK_METHODn.
Then, have your "observer" class receive notifications from "writter" object
using a pointer to the abstract class. This way, you can use dependency
injection to switch implementation during testing phase by creating a mock
"writter" object and passing its address to "observer" object (instead of an address to a real "writter"
object) and setup test cases using EXPECT_CALL on the mock object.
This is the best advice I can give since you did not provide us with a detailed description of your classes.
EDIT:
Concerning the implementation of your real "writter" class: You do not have to create it immediately, you can use the mock class for now to test the behavior of the "observer" class and leave the implementation for later. You will, of course, have to implement it eventually since it has to be used in production code.
This might be a noob question however, I am not entirely sure on the procedures to writing unit tests for an abstract class in Salesforce. The class itself has 3 public methods as well as two abstract unimplemented methods. I unfortunately haven't found much help on the topic.
I know abstract classes cannot be constructed which means I can't create an instance of it to test on. Greatly appreciate any inputs.
What ultimately worked for me was, I used a class that was already extending the abstract class to call the methods I needed to test. I didn't need a mock object or to create a whole new sub-class to test.
You could create a test subclass which would implement those abstract methods with dummy implementation.
That way, you can instantiate this test class in your test: calling its non-abstract methods will run the production code.
Alternatively, you could look into mocking frameworks: they might even remove the need to subclass the class yourself.
I am starting TDD both at work and at home (I know I'm late to the party). I already have several tests for public methods for classes. However many of the classes I write have lots of protected functions. When creating a test class, should I have it subclass the class to be tested so I can have coverage on the protected methods?
Thanks,
Jec
In an ideal world, you wouldn't need to test the protected methods directly, instead you would only be testing through the public interface. However, of course the world isn't ideal, and I don't think it's a bad thing to be testing protected methods if there is a good reason to.
I think whether to sub-class or not depends on the nature of the protected methods:
If they are abstract or blank methods designed to be overridden by a sub-class, and you want to test that the methods are being called, then a testing sub-class is a good way to do this, as you can use the sub-class as a way to intercept these method calls and verify how they were called etc. One thing I would say is to be careful that any logic in a testing sub-class is purely for the purpose of verifying method calls, otherwise you could introduce behavior which may impact your tests negatively (for example, you could easily add logic to a testing sub-class which causes a given test to pass based only on the logic in your testing sub-class, and not the logic in the real implementation).
If they are methods in a class designed to expose functionality to sub-classes, then I don't think that you need to sub-class the class under test. Because the methods are protected scope, different classes in the same package can access them, and therefore all you need to do is have your tests in the same package to call these methods to test them (which in my book is generally good practice, the tests should be in the same package but stored in a different directory).
Welcome. It's never too late for the party!
Creating sub-classes to get access to private or protected methods is perhaps the best way. It creates the maximum "surface" for you to construct your tests.
In other situations, I have created sub-classes to allow me to instrument a class under test, to add factory and singleton patterns to a class under test, and to help allow substitutions of mock objects.
You can subclass the class to test its protected interface.
Or you can let a mocking library do the subclassing. Depending on what the protected interface does, that may be preferable.
Specifically, if the base class uses the template method pattern, creating the subclass as a mock is probably better. If the base class just offers helper functions for the derived classes to use, consider putting them into a separate class and making them public.
You should test public interface of your class.
So you don't need to write unit test for private or protected members.
Your private and protected members are called inside public members so when you test your public members all private and protected members will be tested implicitly as well.
Many would argue that you should only test the public methods of a class.
Subclassing would work for protected properties and methods but would not work for private, internal, etc.
Depending on what language you use you can declare the test class and the class that it tests to be "friends" so the test class can see the other class' properties.
What is the best way to unit test subclasses? Let's assume there's a base class for which I've already written tests and there are some number of subclasses that override some of the parent's behavior in public and/or protected methods.
Should the test class for my subclasses extend (and override test methods where appropriate) the test class for my base class so that all of the base class tests are applied? Otherwise, I would expect to have repeated test code.
According to the Liskov substitution principle, instances of the subclasses, should exhibit the same properties as the base class, and, thus, pass (all ?) the same unit tests.
I would run [perhaps not all, all that are relevant] the base class tests for each subclass. This can be achieved with a test helper.
Yes, subclassing the test class could be a good way to avoid duplication in the unit tests. Have a look at the Testcase superclass pattern.
It is difficult to see without an example, but I would test the base class in one set of tests, and then create new tests for the subclasses and just test the behaviour that differs.