Win a copy of Microservices in Action this week in the Web Services forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

!! Run a Junit test before the deployment of my Java app  RSS feed

 
Ranch Hand
Posts: 1215
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I would like to run a Junit test before the deployment of my Java app. The key to consider is that the Junit tests to run and the Java application are in diferent Git repositories.

Could it works?

Regards, Isaac
 
Isaac Ferguson
Ranch Hand
Posts: 1215
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I forgot to say that for the deployment I would like to use Jenkins
 
Saloon Keeper
Posts: 5052
135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, Jenkins can do that.
 
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In point of fact, if you use Maven (or a similar build tool), that's a standard feature of the build process, done automatically. Jenkins can drive Maven. In fact, it can drive Maven so well that it can present the results of the unit tests graphically.
 
Isaac Ferguson
Ranch Hand
Posts: 1215
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the pom.xml of the app I am trying that an executable .Jar would be generated by using Maven with the next code, but anything seems to be generated at any folder.

 
Isaac Ferguson
Ranch Hand
Posts: 1215
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I forgot to say that for the deployment I would like to use Jenkins



But when the app is in a Git repository which is a different repository that the one hosting the JUnit file. Could someone share an examle please?

 
Tim Holloway
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why would you do that? Standard practice is that the production source is in the Maven /src/main directory tree and the testing (junit) source is in the Maven /src/test directory tree.

Having them in 2 separate git archives means that you also have to check out 2 separate git projects if you want to keep the test sources in sync with their corresponding classes to be tested.
 
Isaac Ferguson
Ranch Hand
Posts: 1215
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is because of security, I have not another option
 
Tim Holloway
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Isaac Ferguson wrote:It is because of security, I have not another option



That's a highly questionable reason.

Junit testing is intended for logic, and keeping the test designers from seeing the production logic (and vice versa) is "security by obscurity", which is not considered an effective means of security. And unit testing should absolutely never be acting on live, sensitive data. A properly-designed Java app uses plug-replaceable resources* so that production resources are kept away from prying eyes and the test data set can more thoroughly exercise pathologies that "aren't supposed to happen" in the live data.

Modern Java development and support systems are designed with best practices in mind and with the active oversight of some of the biggest, most demanding, and - in theory most secure organizations in the world. Which means that if you're having to make extensive overrides to default behaviors that you may actually be making things worse, not better.

====
* That's one of the reasons Java gets badmouthed for all those "unnecessary" abstract interfaces.
 
Isaac Ferguson
Ranch Hand
Posts: 1215
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

It is because of security, I have not another option



It is just to avoid making a commit by mistake when placing the new testing application together with another application in the same repository.



 
Tim Holloway
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now I'm confused.

Each application should be a separate project in the repository. The testing code for the application should be associated with that application and no other. If you have code used by more than one application, then that code should be in a library in a separate project with its own testing logic. And if you're having problems with projects breaking because one project needed a library change but others haven't been converted to handle that change, a Maven build system allows each project to demand a specific version of a library so that they can continue to function until they too are updated. At which time you'd update the version number of the library in that project's POM.

In short, projects should be self-contained. I worked in the barbarous times when stuff was scattered willy-nilly all over the landscape and keeping stuff synchronized was a strictly manual task. It was not fun and people would routinely get dragged out of bed at 2 a.m. to fix stuff. And programs were overall much simpler back then. No GUIs to maintain, no Internet.
 
Isaac Ferguson
Ranch Hand
Posts: 1215
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well the core issue is that no .jar file is generated by Maven. Any idea, please?
 
Tim Holloway
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What, actually, are you trying to produce and what Maven goal are you using to try to produce it?

Because it looks like you are attempting to create an executable jar whose sole purpose in life is to run a Java test application. And that's bizarre, since if you're using Junit with Maven, normally the Maven Surefire plugin would be the test application and the actual Maven product would be a stand-alone JAR (executable or library) or a WAR or EAR or something like that.

Unit tests are UNIT tests. They are run against the compiled classes, not against the final product. So Surefire doesn't even need the jar:jar or war:war goals or any of their downstreams like the assembly goal in order to run, only the compile goal, which is an automatic upstream goal of the maven test goal. And complex goals like the assembly goal run the test goal as an automatic part of their upstream goal chain. An executable test jar just doesn't make sense.

As I said before, it really looks like you're making this too complicated. The best practices are already embedded in Maven and require relatively little POM configuration.
 
Isaac Ferguson
Ranch Hand
Posts: 1215
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just created a batch file and I wrote;



It launches the tests correctly, the thing is that I have a method in the Test.java class called SetUp(), I set the values as literals, I would prefer that the user could write the values itself like for example at the .bat file.

I am not sure if this could be a good and simple approach...Any suggestion, please?
 
Tim Holloway
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, "call" is a DOS command, and I'm not sure that there's any need to use it just to run Maven. But "mvn test" does not require you to build an executable jar because maven itself is executing the tests.

I have no clue as to what you mean by "user set the values as literals". If you mean test data, tests generally work best if they're repeatable, so you'd normally include test data files in the project under the /src/test/resources directory subtree. Unless they're really big files, in which case your shop would hopefully have some server or other where such assets are kept.
 
Isaac Ferguson
Ranch Hand
Posts: 1215
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I have no clue as to what you mean by "user set the values as literals".




This code is the fisrt method to execute in the test1.java file. I would like that from a bat file a user could choose the values.
 
Isaac Ferguson
Ranch Hand
Posts: 1215
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For example, this could for setting the PATH;



But what I try to do is not setting the path but setting values to be used within the Java application.
 
Isaac Ferguson
Ranch Hand
Posts: 1215
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe something like this?

 
Tim Holloway
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please do not confuse the Java application with the Java application test. They are 2 different things, which is why there are 2 different source trees for them in the standard Maven project directory.

Again, it's not considered good practice to have people inputting whatever data randomly pleases them when runnng unit tests. A unit test is intended to not only aid in the initial creation and setup of an application module, it's also intended to run as a regression test when the application is later modified. To ensure that nothing broke. Which is why best practice is to keep the test data in a file or files under /src/test/java and have the Junit test that uses that test data read the test data itself. So, for example:



* disclaimer: I'm writing method calls from memory. Any discrepancy between what I coded and what Java actually requires is because I'm too lazy to look up the details.

As it happens, another suspect feature of this system is that you're using class methods instead of instantiating a RestUtil object. That's questionable design practice even without junit OR maven. And when you're talking unit testing, it makes it harder, since if you want to work with several sets of test input, a more reasonable approach is more like this:



A couple of other notes. First, tests should be done using an identity that's strictly reserved for testing. One that has only the privileges that are required to test with, not general or supervisory priviliges.

Second, you should always test against test resources, not live production ones containing sensitive data or stuff that if you damage will send angry mobs after you with torches and pitchforks. Also, your tests should contain processes to revert or initialize whatever resources they touch. This is especially an issue when testing, for example, database code. Say a test inserts 50 test records. The test cleanup and/or initialization should ensure that those 50 records are deleted so that the next time the test runs it sees exactly the same environment that the previous test did.

Obviously if you're testing something like a Google search, where you're doing a read-only query against a public resource, you don't have to be quite so paranoid, Although in Google's case, the exact same results may not be returned each time you test, so even there, it's better to test against a predictable "mock google".

Third The src/test/resources directory isn't just for preparing tests. If, for example, you're testing a service that returns JSON, you can put a copy of the expected results in src/test/resources for the JSON test methods to compare against. That keeps you from having to hard-code a lot of stuff. This is also true of database logic tests using dbunit.
 
Tim Holloway
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Almost forgot one final note. One of the other principles of junit testing is that it's expected to be completely automated. A Jenkins server, for example, can automatically run "mvn test" whenever new source code is checked in or at midnight or whatever, so having someone sit at a console and type in data doesn't work well that way. And in some shops I've known, the final production build and test is done by non-developer operations staff who shouldn't have to know about the minor details of the system. And, alas, often aren't paid enough to want to know.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!