Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
Code of the if statement:
if (reponse.getStatus() >= HttpServletResponse.SC_BAD_REQUEST) {
LOGGER.error("Erreur lors de l'enregistrement de la trace technique - {}", reponse.getStatusInfo().getReasonPhrase());
}
Basically testing always consists of two parts:
preparing some input, so that your production code under test takes a specific path
verifying that the expected "things" happened
First one is easy: you have to somehow make sure that the response object that your production code is dealing with has the required status. How you do that, very much depends on context.
For the second aspect, that is probably hard. You see, the only action taking place is a (probably static) call to that error() message. If that is the case, then your only way of testing this would be to use JMockit or PowerMock(ito), because those two frameworks allow you to verify static method calls.
So, the real answer is:
figure for yourself how you can gain control over that response object
buy into using one of these mocking frameworks (not recommended)
rework your code so that it becomes testable without adding that (imho really really bad) dependency towards PowerMock(ito).
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 4 years ago.
Improve this question
Every answer on stack overflow provides information on how to replace switch or if else with polymorphism but
the switch, if else constructs also help in providing different behavior of an object with respect to context and inputs.
Why if else,switch is not considered as a part of polymorphism.
Conditional becomes a code smell when we have to check an object’s type in order to make some logic or behavior decision. It doesn’t matter whether it is a stack of if/else block or a switch statement.This violates open-closed principle.
The open closed principle states that the entities(classes, modules, functions etc) should be open for extension,but closed for modification.Which means that these entities won't be allowed to make changes in its source code.
This can be achieved through Abstraction and Polymorphism.
Benifits of Polymorphism over Conditionals
instead of asking an object about its state and then performing actions based on this, it is much easier to simply tell the object what it needs to do and let it decide for itself how to do that.
Removes duplicate code. You get rid of many almost identical conditionals.
If you need to add a new execution variant, all you need to do is add a new subclass without touching the existing code (Open/Closed Principle).
Polymorphism in a concept that allows an Object to retain behavior and properties from its parent classes. Explained further here and here
if, else and switch are procedural code constructs.
The two have nothing in common.
Edit: Thanks #Ted Hopp, correcting my post.
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 am new to Mockito and I have started to learn it. But I have some questions. Why do we need to use Mockito? As far as I know it is used to Mock(Create dummy object) and write the test cases before having actual running code. But, what if I want to test my already implemented code to check whether they are functioning properly or not. How would I test it using Mockito?
For instance, I have CRUD methods and I would like to test whether Create is functioning properly by actually inserting data in database using my Create method, similarly for others. Can we attain it using Mockito. If not, then do I need to write different testcases for them without using Mockito?
The Mock is used to each class or service you are using. The class under test should not be Mocked. Lets assume you are connecting to a remote service which is being built by one of your engineering team, and you are not familiar with its internal functionality but you know what requests and response it returns.
In that case, you can create a Mock of that Object, and defines it with set of responses returns in different situations. Each situation should get its own different test and for each response you should check separately the reaction of the code (you are working on).
Another great example is creating a limitation checks. Lets think of exception that might be thrown in some situations.
You can Mock the object that will throw the Exception which is simple(~2-3 line of test code if you are using Mock) and you can check how the code you have written reacts to that Exception. Without the Mock the throwing of an exception might be really complicated thing and not so easy to use if you are not familiar with the small details. And of course the Mock enables you to be on focus of the main functionality you are checking cause it make the checking time very very small. And that is a bless when time to market is a critical thing.
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 7 years ago.
Improve this question
I think javadocs are beautiful. Clear descriptions for each method and class. Our tester can easily write unit-tests without repetitive explanations from programmers.
This is how we practice TDD at our start-up. We first sit and plan the application structure, and we start creating all the methods and classes (without programming), we add descriptions to the classes, constructors and methods with javadoc. We then ship this to our tester who write unit tests. When he is done, we start programming.
No one is actually complaining. Our tester is in love with javadoc and although he is a terrible programmer (that is why he became a tester), he can easily understand the javadoc and write junit-tests.
The thing is, most of us are newbies in a start-up. And I don't know if you are supposed to document all the classes and methods before we even start programming? My question to you more experienced programmers is: is this a good TDD approach?
TDD is useful, because it makes sure you do not miss any requirements. It ends up beings used as unit test cases, and while the programmer starts their work they need to make sure all the test cases are covered.
Testers write system & integration test cases.
coming to javadoc, ideally it should be a must. It removes code duplication/reusablity and also adds some value to system document.
Javadoc should describe the return type, input params and process being carried out within the method.
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 7 years ago.
Improve this question
I recently started a project in Java, that contains a class called System. This class (Luckily) contains methods for output management, so in the rare cases where I need to use the System. methods (Or the System object in general) I just reference it as java.lang.System.. I believe that this could be looked down upon, as System could be looked at as a reserved name. I currently am in the beginning stages of this program, and could change it accordingly quickly, as there are little calls to the class itself.
While it's not illegal, you don't want to do this. If I were the next person working on your code, the first thing I would do is try to remove "java.lang" from "java.lang.System" and then get miffed when it wouldn't compile.
The idea is to go toward brevity and only write what you need to write, while making sense of it all for the next person. It's more an art than a science.
You could always name it something like ProjectnamehereSystem or OutputManager or something to that effect.
I would not create something so similarly named as an important class. While everything is easy to edit, you may be able to keep up with all the changes you are making.
But when the project evolves things will get messy and complex. I would suggest naming it something else that can be easily distinguished.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I know abstract classes and interfaces in java but I want to know how to bring abstraction in working software/project? how to thing in such way which brings abstraction.
Your question is vague at best, however the usage of interfaces helps abstraction because you are not working with concrete types. For instance:
IPrinter p = PrinterFactory.getPrinter(conditions);
...
p.print(content);
In the below line, you are not aware of exactly what printer you are using. Since you are just using the logic, you do not really care. All that you care about is that the factory will give you the printer you are after and that the print method will print the content to the right stream.
If you want to change the printer being used, you make the amendments in the factory class so that you get a different IPrinter implementation which does what you need (which in this case it would be to print to some other media). This would mean that you have essentially changed the outcome of a piece of code without changing much of it.