Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
My question is how mocks objects are created not how to create a mock object using a library.
I have looked at the Mockito library source code but I didn't understand how its done. I have searched in the Internet but the articles explain what are mock object and how to create them using libraries.
For dynamic programming language perhaps it's simple as we can change methods, variable but how its done in static programming language (Java for example)
Let's begin with what a mock is: an object that you can set expectancies on it regarding methods that expects to be called, and/or parameters on those methods and/or count of calls on those methods.
Mocks are sent to tested objects in order to mimic certain dependencies without having to use the real code (in many cases this is problematic/dangerous, like dealing with payment gateways).
Since mocks will need to intercept calls to all (or some, in case of partial mocks) methods, there are several ways they can be implemented, depending mainly on the features the language provides. Particularly in Java this can be implemented via proxy classes: https://stackoverflow.com/a/1082869/1974224, an approach that kinda forces you (but in a good way) to use interfaces in your code when relying on dependencies.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Today I had an interview for test automation in one of the MNC.
They asked me "why do we need to create an object?"
I explained about OOPs concepts with example of individual bank account holders. But he is not convinced. He just need a definition.
What could be a suitable answer for that question?
You require an object to represent state.
At the most simple definition, a class defines behaviour and an instance of a class (an object) represents state.
Of course there are other things like static contexts which can also maintain state, which you can mention also, but above is the clearest answer which I believe they were looking for.
It also always helps to give an example. You could talk about, for example, an Employee class. You would need an object to represent John and another to represent Jane.
I think that this question is kind of generic and does not give much value to an interview. But some generic question should have a generic answer, and here is mine:
We need to create objects in java so we can get instances that have a state inside our application. This allows us to have persistent encapsulated elements that contain any required information, and methods that operate with it.
Just plain basic OOP theory.
There are many reasons why we create a object apart from basic oops
1) To bring up persistent state data to transactional state to perform action (curd and other) and persist back to data storage.(EJB, POJO,etc )
2) Creating handler to serve service and send fluid data across wire like web-service.
3)Stuctural behavior in action.for example you designed a class for a workflow and to make in action state we create a object and serve the behavior example validation , authorization , etc class
All in all to make design time architecture to response based live system
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I was looking at some code today and I came across a piece of code using reflection to take a generic object and do different things with it based on the the type. I have never seen anything like this before, and I am wondering what are the pros and cons to using reflection in java?
There are no pros or cons of reflection in Java. It's a tool which you should use in a specific situation. For example:
When you create a library which needs runtime manipulation with code.
When you have compiled jar without source code and author of jar made a mistake and didn't expose proper API.
So basically there is even no question should you use or not use reflection, it's a matter of situation. You should NOT use reflection if it possible to do the job without using it in 99.99% of cases.
UPD
Couldn't you use it for everything though? Like if you were a really big jerk you could use it to invoke every method you call, so what is stopping you from just doing that?
Mostly slowness, unmaintainable code, losing of compile time code check, breaking of encapsulation.
using reflection to take a generic object and do different things with
it based on the the type
In general, this is usually a bad idea, for reasons of performance, clarity, and robustness.
It throws away the advantages of a static type system; if you pass in types that the reflection code doesn't handle then you will get runtime errors rather than compile-time errors. If one of the classes changes implementation (e.g. renaming a method) then this will also not be detected at compile time.
If these various types have something in common, then it is usually better to handle this using polymorphism: abstract out the commonality into an interface or abstract class; each subclass can then implement the specific behaviour it needs, without other code needing to poke into the internals using reflection.
If these various types don't have anything in common, then why are they being handled together?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Recently I am working on an applications (in Java and C#, but I think the problem is not closed to those languages) where I use a few container classes (which responsibilities are storing data in a proper order) and services being method packages, operating on data stored in container classes. All of the classes mentioned above should have only one copy existing in memory, and all of them are expected to be in the memory for the whole time the application is running.
I used to think that a singleton is a good idea here, as I am sure there is only one instance of each class, so it meets my expectations. However, I learned that the Singleton pattern is deprecated, as it hides dependencies and so on. Then I heard that for such usage (always available container class or method package) static classes may be a good idea. On the other hand I recently looked at a few projects where people refused to use any static stuff, as if it was an awful practice to do so.
My question is simple (at least in its formula): are static classes a good idea for creating always available, easy to hanlde containers and method packages? If not, what should I use instead (if not singletons)?
You don't really say where the data comes from. If the data is static, then a static class is a fine solution. For example, I could envision a static class to represent the 50 US states.
In contrast, for a class that represents a list of authorized users, I would use a singleton pattern. Although there is only 1 list, that list could change while the app is running.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been hunting for tips on good Java coding practices, by looking at the code of accomplished programs. My first target was Minecraft, since I'd tried my hand at modding it, and I started to question my choice. Here was code from an accomplished game, and it was giving me two very different ways to go about things.
For those who don't know, Minecraft instantiates its items once and subsequently references that single instance and its methods for any operations it needs to carry out, using information from other sources for the method parameters. Its entities, on the other hand, are instantiated once for every individual entity in the world and are responsible for their own information.
So, the crux of the issue is: Which method is more efficient? Is there a particular reason to favor one over the other? Is it situational? Is it more efficient to do it one way or the other?
The answer is, in most cases, it depends.
What you describe is the singleton pattern, which there's one and only one instance of an object. This is beneficial if having more than one instance is either expensive (such as multiple instances of a DAO), or doesn't make much sense (such as multiple instances of a DAO).
Individual instances of objects is necessary if you hold two separate, distinct instances of the same class - for instance, say you're holding two diamond pickaxes. I wouldn't imagine that a singleton would make sense in that context, since you can interact with each pickaxe individually.
Use the pattern most suited for the situation. There is (and won't ever be) any one-size-fits-all way of solving problems like this.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
How would you tackle the following problem?
I've got an API which validates tokens (which are just simple XML files). So the API specifies a bunch of validation methods like validateTime(String tokenPath), validateFileHash(String tokenPath) or validateSomthingElse(String tokenPath).
The API is already implemented in two different languages, Java and C. My task is to make sure, that both versions behave the same. So if Java throws a TokenExpiredException after invoking validateTime("expiredToken.xml"), C should return a corresponding error value (in this case a predefined -4 for TOKEN_EXPIRED).
The good old approach would be to write Unit/Integration-tests in both languages. However, this would require double the effort as I would have to implement essentially the same Tests in Java and in C.
My idea was to define a XML-Schema for TestCases which would look something like this.
<!-- TestCases.xml -->
<testcase>
<tokenpath>expiredToken.xml</tokenpath>
<apiMethod>validateTime</apiMethod>
<expectationJava>TokenExpiredException</expectationJava>
<expectationC>-4</expectationC>
</testcase>
<testcase>
...
</testcase>
Furthermore, I would build a small Java tool to parse TestCases.xml and directly invoke both API versions (using JNI for C) to match the outcome to the preset expectations.
Do you think this is a feasible plan, or is it better to do the old approach? Are there Frameworks to deal with this kind of tasks or is it a smelly idea to begin with?
Your approach is feasible, what would be even better is if you can take advantage of some existing data driven testing frameworks. This way you don't need to do the legwork of parsing inputs, running test cases and asserting outputs.
Here's an example of how to drive Java tests through JUnit + an excel spreadsheet containing the data: http://www.wakaleo.com/component/content/article/241
I didn't see one immediately, but hopefully you can find something similar for C.