I'm following this tutorial: http://jeantessier.com/SoftwareEngineering/Mocking.html#jMock
I am trying to mock a class.
I don't understand what the Imposteriser does? http://www.jmock.org/javadoc/2.5.1/org/jmock/api/Imposteriser.html
Thanks
This is described in the MockObjectTestCase JavaDoc. Essentially an Imposteriser is a strategy for creating mock objects.
By default, MockObjectTestCase will only allow you to create mocks for interfaces, not classes. If you would like to mock interfaces and classes, you need to tell MockObjectTestCase to use a different strategy for creating mocks:
setImposteriser(ClassImposteriser.INSTANCE);
Related
I am writing junit test cases for a spring boot application. I am having lot of doubts and I have listed them below.
Is it enough to write unit test cases only for service layer?
How to re-use the stubs / mocks created for the models. Each model is created with lot of dependencies. If we don't reuse them, we will be creating the same objects again and again. If we reuse how to accommodate the test values for all test cases?
Is there any best practices when creating the stubs?
Do we need to write the unit test cases for utility methods?
Rest controllers needs unit test cases?
I'll try to give the best general answers, though keep in mind that the specific case might require different approach.
No, generally speaking you should test everything that contains logic which might be subject to maintenance, and therefore unwanted changes.
I'm not quite sure on what is the problem here. The way I understood it, you want to write the stubs/mocks once and use them for multiple tests; maybe, you might use one test class and generate the stubs in a #Before, #BeforeClass annotated methods.
Well, the stub is intended to be used in place of a specific method when provided a given input. So, first, you should identify what inputs your stubbed method is going to receive and be sure you are passing them along (Note: if you provide the wrong inputs the stub won't work). Second, you need to stub the return object or the answer. Anyway, you might need to use sequential stubbing for cases when the method is called multiple times and different returns are required.
Yes, a maintenance change might cause the change in the behavior of such methods heavily affecting the product. You should always use JUnit to constraint the logic. Anyway, utility classes should be trivial and I don't expect it to be difficult for you to test them.
Like I already said, if it contains logic, yes, it should. Anyway I kinda remember there are different frameworks to mock rest calls.
Daniele
I'd like to be able to register some types on a container and then top these up with some additional type declared in an XML configuration file. Unfortunately, IConfigurationInterpreter (implemented by XmlInterpreter) is only available in the WindsorContainer() constructor, not in any AddXXX() methods. Is there any other way I can achieve this without resorting to parent/child containers (that may soon be unsupported).
Background: Our large application is only starting to use the Castle framework to register and resolve some of it's components. Because Castle is being retrofitted into this app we're using a singleton class to maintain a global instance of WindsorContainer(). In unit tests, we need to wire up this container instance to use a combination of custom mock implementations (specific to the test) + some default mock implementations. For DLL dependency reasons, these mock class types are unavailable in this unit test fixture abstract base class so dynamic registration (using strings) is necessary. I was hoping to use an XML resource file to register the default mocks. Otherwise I have to do the same using an IWindsorInstaller implementation that's really duplicating what XmlInterpreter does. This API appears to be forcing this direction.
I think these will work ...
container.Install(Castle.Windsor.Installer.Configuration.FromXml(resource))
OR
container.Install(Castle.Windsor.Installer.Configuration.FromXmlFile(path))
which both avoid use of the IConfigurationInterpreter interface.
I am trying to build a domain model with business methods and have EF 4.1 doing the persistence for me. So far so good.
Problem is, all properties are exposed as public on my domain classes. That's at least what I learnt from the tutorial anyway. That means, I have no strong proof that class properties won't change by some careless programmers outside of business methods. Encapsulation violated.
I tried introducing ISomething but TableAttribute applies only to classes, not interfaces, so I can't tell EF to do DBSet. If I leave TableAttribute to classes but make Something implement ISomething anyway then I can't do DBSet.Add() because EF doesn't know ISomething.
The only way I can think of is write a complete abstraction layer on top of EF 4.1 for CRUD using interfaces. Under the hood, do the type translation between Something and ISomething. It sounded a lot of complexity and a gaping hole in EF's design. Or I must've missed something.
How would you solve this?
Many thanks.
Problem is, all properties are exposed as public on my domain classes.
That's at least what I learnt from the tutorial anyway. That means, I
have no strong proof that class properties won't change by some
careless programmers outside of business methods. Encapsulation
violated.
How this will be solved by interface? Interface will again expose all properties as public and EF demands that property must have getter and setter.
EF is not able to work with interfaces. When using EDMX for mapping it is possible to play little bit with properties' accessibility but when using code first it is much worse because mapping is affected by the same accessibility rules. Creating abstraction layer on top of EF is mostly same as not using EF at all. Once you create abstraction you cannot use linq-to-entities directly and you will lose main reason for using EF.
Your problem is more about: Where is the boundary? If you want to work with entities only in business methods you should not expose them from these methods. If you want to make sure that properties are correctly handled perhaps you should implement validation logic directly into the entity.
I am developing an AS3 application which uses a Singleton class to store Metrics in Arrays. It's a Singleton because I only ever want one instance of this class to be created and it needs to be created from any part of the app.
The difficulty comes when I want to unit test this class. I thought adding public getters and setters would enable me to unit test this properly and would be useful for my app. I have read that changing to a Factory pattern will enable unit testing or using Inversion of control. This would of course make it more flexible too. I would like to know of people's thoughts on this matter as there are SO many conflicting opinions on this!
Thanks
Chris
If you're using an IoC framework, then make your consumers require an instance of the service in their constructor, and configure the IoC framework to only build one instance and keep handing it out to all requests in the entire application. This is the default behavior of Castle Windsor in my experience.
For unit testing you can use a Mock object in place of the real object.
This question already has answers here:
Interface vs Base class
(38 answers)
Closed 12 months ago.
I have been getting deeper into the world of OOP, design patterns, and actionscript 3 and I am still curious how to know when to use an Abstract class (pseudo for AS3 which doesn't support Abstract classes) and an interface. To me both just serve as templates that make sure certain methods are implemented in a given class. Is the difference solely in the fact that Abstract classes require inheritance and an Interface merely extends?
Use an abstract class if you have some functionality that you want it's subclasses to have. For instance, if you have a set of functions that you want all of the base abstract class's subclasses to have.
Use an interface if you just want a general contract on behavior/functionality. If you have a function or object that you want to take in a set of different objects, use an interface. Then you can change out the object that is passed in, without changing the method or object that is taking it.
Interfaces are typically loose, compared to Abstract classes. You wouldn't want to use interfaces in a situation where you are constantly writing the same code for all of the interface's methods. Use an abstract class and define each method once.
Also, if you are trying to create a specific object inheritance hierarchy, you really wouldn't want to try to do that with just interfaces.
Also, again, in some languages you can only have a single base class, and if an object already has a base class, you are going to have to do some refactoring in order to use an abstract base class. This may or may not mean that you might want to use an inteface instead.
As #tvanfosson notes, it's not a bad idea to use a lot of interfaces, when you really understand abstract classes and interfaces, it's not really an either/or situation. A particular situation could use both abstract classes and interfaces or neither. I like to use interfaces sometimes simply to restrict what a method or object can access on a passed in parameter object.
Abstract classes offer the possibility to implement specific methods and require others to be implemented in the inheriting class. With interfaces, everything has to be implemented in the implementing class.
As #m4bwav notes, the primary difference is that an abstract class can, and often does, provide a default implementation for at least some methods. This allows you to use the abstract class to keep your code DRY (don't repeat yourself), by keeping code common to all classes that inherit from the abstract class in the abstract class itself.
I think it's a false dilemma, though. You don't need to and arguably shouldn't choose between interfaces and abstract classes. In most cases, you would want to define the interface, then have your abstract class provide a default, skeleton implementation if one is required/desired. For me the question would be do I need an interface or an interface and an abstract class rather than an interface or an abstract class. Using the interface decouples your code from any particular implementation, even your abstract class implementation. If you should choose to have an alternate implementation, using the interface would allow this whereas if you only had the abstract class, you'd have to refactor to add the interface later.
The only situation where I can see that providing an interface in such a situation would not be desired is where you want to restrict it so that only your implementation can be used. Using the abstract class and having certain methods be not be virtual would enforce the use of your code in all circumstances where the implementer is deriving from your class.