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 6 years ago.
Improve this question
I have an eclipse (not maven) project in which I organize the code in two source folders: src and test.
The hierarchy of test folder is parallel to src to make it easy to find classes and stay organized.
Now, I was talking about my unit tests. I'd like to separate unit tests from my integration tests as well, but I'm not sure what would be the best way of doing so.
Maybe I should have another source folder just for my integration tests? Or maybe it should be under a separate package in test source folder?
I will be happy to hear how you do it, thank you in advance.
Personnal opinion (because that's all about personnal preferences here) is : separate packages for different test level
src/ //source folder
...
test/ // source folder
test/ //packages
integration/
unit/
tools/
I personally stopped maintaining the source package hierarchy for test classes since I found it very costly when you refactor your sources.
I also use the JUnit Categories to clearly separate test level in a visible way.
Your intuition is good: another source folder is probably the best option. Usually people name it something like: it, test-integration, test-it, integrationtest.
If you are using Maven as a build tool, this can be achieved by build-helper-maven-plugin. If not, just add manually in your IDE another source folder.
Related
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 3 years ago.
Improve this question
Problem statement: Every service has a separate repository. what is the best way to use a common framework across several service repositories?
We are trying to create an API test automation framework using "Karate".
Here we want to create a framework(Which can be distributed(example:jar)) such that it can be used across all of the microservice project repositories.
As the creator of Karate, I strongly recommend you don't do this. In the long term this makes all your projects depend on one common framework - and you should try to reduce the creation of "home grown" frameworks. Especially for a testing framework, you should try not to force teams to depend on an additional library which you need to maintain and version-control. Re-use can cause more harm than good especially in the context of testing, see this article at the Google Testing Blog.
That said, since Karate can read files from the classpath: you can "ship" a JAR file with common Java classes and even feature or JS files that all your projects can inherit from or "re use". In fact the karate-base.js has been designed to solve for common bootstrap logic or variables / parameters being supplied from a JAR file.
Short Answer: use normal Java techniques (Maven / Gradle) to create a re-usable JAR file. There are multiple ways to use resources (Java, *.feature, JS) from a JAR file. It is up to you how to structure your Maven (or Gradle) projects to make this happen.
EDIT: for those looking for how to create a "runnable" JAR, please see https://stackoverflow.com/a/56553194/143475
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 3 years ago.
Improve this question
Problem statement: Every service has a separate repository. what is the best way to use a common framework across several service repositories?
We are trying to create an API test automation framework using "Karate".
Here we want to create a framework(Which can be distributed(example:jar)) such that it can be used across all of the microservice project repositories.
As the creator of Karate, I strongly recommend you don't do this. In the long term this makes all your projects depend on one common framework - and you should try to reduce the creation of "home grown" frameworks. Especially for a testing framework, you should try not to force teams to depend on an additional library which you need to maintain and version-control. Re-use can cause more harm than good especially in the context of testing, see this article at the Google Testing Blog.
That said, since Karate can read files from the classpath: you can "ship" a JAR file with common Java classes and even feature or JS files that all your projects can inherit from or "re use". In fact the karate-base.js has been designed to solve for common bootstrap logic or variables / parameters being supplied from a JAR file.
Short Answer: use normal Java techniques (Maven / Gradle) to create a re-usable JAR file. There are multiple ways to use resources (Java, *.feature, JS) from a JAR file. It is up to you how to structure your Maven (or Gradle) projects to make this happen.
EDIT: for those looking for how to create a "runnable" JAR, please see https://stackoverflow.com/a/56553194/143475
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
When do we need to attach source to a jar?
Can we debug without attaching the source code?
Can we see the stacktrace line numbers without the source (AFIAK we can't)?
What is the best practice for local builds? Do we need the source code?
What about CI?
Can we leave the source code only for production release?
Thanks,
Omer
It's good practice to also publish the sources jar along with your binary jar in your internal (or external) Maven repository. It makes life of the developer that is working with your code much easier since they can see your comments / browse the codebase and be able to have all that at debug time. Now as you are saying even if the sources jar is not published, developers have ways around it primarily relying on their IDE. In Eclipse for instance you can install the Java Decompile plugin that would give you access to the code during debug time or on IntelliJ there is something similar without the need of installing a plugin.
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 would like to add some sort of unit testing to an IDE known as "IBS Integrator".
how the IDE works:
I write "java-ish" code in .itr files.
when I press the run button these files are compiled into .class and .java files.
I have no idea what happens next.
Does anyone have advise on how I could make unit testing work in a setup like this?
I was hopping for a framework like phpunit or rspec. I know they are for different langagues but a similar tool for java would be nice. I'm not sure what (if anything) can interact with .class/.java files.
I would prefer something open-source if possible.
Since IBS Integrator compiles to .class files, you should be able to write JUnit tests in Java against those classes, and run them however you'd normally run JUnit tests (kick off Ant or Maven, open Eclipse and run them from there, etc.). And I can't think of any reason to use another technology (phpunit, rspec, etc.) for writing tests of Java code; JUnit seems like the clear winner here.
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
this is a source file organization question -
I used to create separate Eclipse Projects for solutions to example problems I solved ( eg: the first one is for Exercise 1.1.2 ). Each project has a single java file with a main() function that does the work/testing. So as I keep adding new solutions the number of projects grows which is pretty unwieldy. And each project has just one java file, so there must be a better way to organize these.
What are some good ways/best practices to consolidate all these into a single project?
( Just stick the files together/ have a single main method, etc.. )
Here's what I would do. Create one project in Eclipse called "Exercises". The project should have one src folder and one test folder. Group your code into packages as suggested in another answer; com.exercises.chapterone, there either create a java class for each exercise, or one large class for each chapter with separate methods for each exercise.
Then create JUnit tests that mirror your code and run each class/method to verify that it works. You don't need a main class to run code. This will keep your workspace small and tidy and it will help you to learn how to unit test your code. This is a very important thing to learn, so the sooner you start to do it, the better.
So, something like this
Exercices
src
com.exercise.chapterone
Exercise1.java
oneOneOne(...)
oneOneTwo(...)
Exercise2.java
test
com.exercise.chapterone
TestExercise1.java
TestOneOneOne(...)
TestOneOneTwo(...)
TestExercise2.java
A place to start would to put them in one project and group them logically in packages.
E.g. you can put all 1.1 exercises in a package named com.exercises.oneone.
Firstly, you can group your exercises using packages, one exercise per package.
And then with each exercise, provide one entrance method for test, instead of a main function. And at last, you can run test using some testing libs such as junit, or you can even write a single main function to test all your exercises.
If you require independence between exercises, with junit, you can run each test case independently. While using single main function, you can pass some args into the main and determine which exercise to run.
Hope this will help you.