We are planning to customize the PMD as per our project standards (Technology: Java and sales force).
We have JUnits too in our project and we have hard coded strings for JUnit execution.
How to set a rule to avoid the JUnits hard coded strings in PMD rule set?
Related
Could you please outline new major features of JUnit 5 in comparison to JUnit 4?
What are new annotations, if any, and what they are used for (if few words)?
JUnit 5 programming model remained almost unchanged. We still have to use annotations to declare test and life-cycle methods.
At first sight there are no big changes. However, they exists:
Neither test classes nor test methods need to be public.
#Test annotation does not have additional parameters
Life-cycle annotations were renamed
#BeforeAll / #AfterAll
#BeforeEach / #AfterEach
#Disabled is the analogous to JUnit 4’s #Ignore
Also some changes was made for Assertions and Assumptions:
The optional message is now the last parameter
Assertion messages can be lazily evaluated using Supplier<String>
Now it is possible to assert boolean condition using BooleanSupplier
Also JUnit 5 introduced some new concepts into programming model:
Tagging and filtering
#Tag and #Tags used to declare tags for filtering tests, either at the class or method level; analogous to Categories in JUnit 4
#Nested test classes
For better grouping and organization, shared initialization state.
#DisplayName
Allow to declare custom display names — with spaces, special characters, and even emojis — that will be displayed by test runners and test reporting.
Dynamic tests
Useful when you need to run the same set of tests on many different input values or configurations.
JUnit 5 doen't support anymore Runners and Rules. These partially competing concepts have been replaced by a single consistent extension model.
Since test execution follows a certain life cycle. And each phase of that life cycle that can be extended is represented by an interface. Extensions can express interest in certain phases in that they implement the corresponding interface(s).
Using extensions you can implement:
Conditional test execution
TestExecutionCondition
ContainerExecutionCondition
Constructor and methods parameters resolution (dependency injection)
ParameterResolver
Exception handling
TestExecutionExceptionHandler
Handle test life-cycle
TestInstancePostProcessor
BeforeAllCallback
BeforeEachCallback
BeforeTestExecutionCallback
AfterTestExecutionCallback
AfterEachCallback
AfterAllCallback
Can we use JUnit to test java batch jobs? Since Junit runs locally and java batch jobs run on the server, i am not sure how to start a job (i tried using using the JobOperator class) from JUnit test cases.
If JUnit is not the right tool, how can we unit test java batch code.
I am using using IBM's implementation of JSR 352 running on WAS Liberty
JUnit is first of all an automation and test monitor framework. Meaning: you can use it to drive all kinds of #Test methods.
From an conceptual point, the definition of unit tests is pretty vague; if you follow wikipedia, "everything you do to test something" can be seen as unit test. Following that perspective, of course, you can "unit test" batch code that runs on a batch framework.
But: most people think that "true", "helpful" unit tests do not require the presence of any external thing. Such tests can be run "locally" at build time. No need for servers, file systems, networking, ...
Keeping that in mind, I think there are two things you can work with:
You can use JUnit to drive "integration" or "functional tests". Meaning: you can define test suites that do the "full thing" - define batches, have them processed to check for expected results in the end. As said, that would be integration tests that make sure the end-to-end flow works as expected.
You look into"normal" JUnit unit-testing. Meaning: you focus on those aspects in your code that are "un-related" to the batch framework (in other words: look out for POJOs) and unit-test those. Locally; maybe with mocking frameworks; without relying on a real batch service running your code.
Building on the answer from #GhostCat, it seems you're asking how to drive the full job (his bullet 1.) in your tests. (Of course unit testing the reader/processor/writer components individually can also be useful.)
Your basic options are:
Use Arquillian (see here for a link on getting started with Arquillian and Liberty) to run your tests in the server but to let Arquillian handle the tasks of deploying the app to the server and collecting the results.
Write your own servlet harness driving your job through the JobOperator interface. See the answer by #aguibert to this question for a starting point. Note you'll probably want to write your own simple routine polling the JobExecution for one of the "finished" states (COMPLETED, FAILED, or STOPPED) unless your jobs have some other means of making the submitter aware.
Another technique to keep in mind is the startup bean. You can run your jobs simply by starting the server with a startup bean like:
#Startup
#Singleton
public class StartupBean {
JobOperator jobOp = BatchRuntime.getJobOperator();
// Drive job(s) on startup.
jobOp.start(...);
This can be useful if you have a way to check the job results separate from using the JobOperator interface (for which you need to be in the server). Your tests can simply poll and check for the job results. You don't even have to open an HTTP port, and the server startup overhead is only a few seconds.
I have an application running on JBoss AS 7.1.1. This app uses some resources of CDI specification as interceptors, injection, etc. The architecture of my app is very simple with the structure below:
view (xhtml and facelets)
controller (managed beans with #Named, except in the ViewScoped)
model (divided in two layers, service and dao)
service (with #Stateless annotation, here I use an interceptor that I created to manage the transactions with database, because I use native JDBC)
dao
I need to create some scripts to test the application service layer, injecting the service implementation and invoking the business methods.
I believe that this architecture is very common. I'm sorry for my english.
Can someone help me, please?
Thanks!
If you want to test your full container, you probably want Arquillian. If you want to do Unit testing with mocks, start a standalone weld container in your test using weld-se.
new Weld().initialize().instance().select(YourClassName.class).get();
You can substitute your mock objects by using alternatives in your beans.xml. You can also use CDI-Unit which simplifies the process a bit.
I'm following this guide http://javaeenotes.blogspot.com/2011/06/short-introduction-to-jmock.html
I've received the error
java.lang.SecurityException: class "org.hamcrest.TypeSafeMatcher"'s signer information does not match signer information of other classes in the same package.
In the guide the author says:
The solution is make sure the jMock libraries are included before the
standard jUnit libraries in the build path.
What makes up the "standard jmock libraries" and the "junit libraries"?
Junit only has one jar so that's easy, but jmock comes with over 10 different jars.
I've been using: j-unit4.10, jmock-2.5, hamrest-core and hamcrest-library
What are the hamcrest core and library classes for?
i'm a committer on both libraries. JMock depends on hamcrest to help it decide whether an call to an object is expected. I suggest just using the hamcrest-all jar. The split between hamcrest core and library was to separate the fundamental behaviour of matching and reporting differences from a convenient implementations of the most common cases.
Finally, if you're using hamcrest, I suggest you use the junit-dep jar to avoid clashes with some features of hamcrest that are included in the junit.jar
JUnit is used to do Unit test in order to test your methods. JMock is used to test your program inside a context, You will have to know what you are expecting to send to the context (ENV) and what will answer the context.
JMock use JUnit, that is why, in order to avoid dependency conflicts, you need to include it before JUnit.
The 10 libraries of JMock are kind of add-ons if you need to use JMock script or any other functionnality not available in the JMock core.
You don't need to know about Hamcrest-core library to use JMock. Just follows the guide on the web site (don't use version 1 of JMock) and Organize your libraries in the correct order (JUnit should be last in order to avoid your error)
mock frameworks licke jmock do some black magic behind the scenes
( including, but not limited to runtime byte code manipulation )
to provide mock methods classes and whatever. To be able to do this,
some tweaks in basic junit classes are necessary, and the only way to do this is to
register itself as java agent before JU classes are loaded.
Also, put your mock framework before junit in classpath
I'm in the middle of setting up PMD as a tool in our team to support us writing better code. Basically I'm building Ant scripts and try to set up some rules for everyone to use.
But right now I hit this problem:
When I write JUnit tests I don't want to use the same rules I apply on our main source code. I don't care that much about String rules (like string dupliates or weird instantiations) in the junit tests.
My questions is:
Is that a fault on my side and should I start writing better JUnit tests?
Should I provide a 2nd set of rules that disables some of the string/design/finalizers rules?
The second option - I don't run PMD against my tests at all. I could and PMD provides some JUnit specific rules. I would definitely use a separate ruleset against the test code though. I expect more String literals and some thing specified instead of using conditionals/loops. After all, I don't want to duplicate the code I am trying to test.
Two things. Why are you trying to set up rules why not using the existing rules? (Special requirements?). And second yes of course Unit tests should have a good quality as well. Your Unit test test you production code so shouldn't they have at least the same quality as your production code?