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.
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 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
I am working on a very old application built using strut 1.1 in 2004. The complete application is made by combining three projects(common, web, and EJB) in Eclipse and all these three are packaged as.EAR file. So here the confusion where to fit the JUnit test cases for this type of structure.
Whether I should create a separate project for writing the test cases. If I create the separate project, I would add the above projects in the build path.
So what is the right way? Any suggestion would be appreciated.
Also, tell me about the way I can check the results on GUI that how many cases are passed and how many are failed.
First of all: in case you intend to write real JUnit unit tests for 14 year old code, the answer is: do not do that.
If at all, you should be using JUnit as environment to automate test case execution, which in this case should be "integration" or "functional" tests.
You see: the only reasonable argument to invest money in old, existing source code is: you intend to refactor/replace that solution with a new implementation. Then your one and only concern is that your new code behaves like the old one. From a functional point of view. It doesn't make sense to invest time/energy into unit testing units you intend to throw away soon.
Beyond that: do whatever works for you. Typically, it would be better to have a complete new project to avoid tampering anything existing.
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.
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 8 years ago.
Improve this question
I am splitting my project up in to packages and this is the first time I have used this, I normally just use the default package in eclipse but i read this is not the best idea.
What i was wondering is how granular do you make projects.
I have split distinct classes in to logical groups of functionality but this leaves some stragglers left over at the end in the top root of my main package. Is it ok to just leave those there or should they have their own package?
Thanks
leaves some stragglers left over at the end in the top root of my main package. Is it ok to just leave those there or should they have their own package?
If those "stragglers" contain functionality used by the other classes, it might be better to put the in a "util" subpackage. Top packages usually contain classes that serve as a central access point to a framework or API, or (in the case of an application) that contain the main method and set up everything else.
What stragglers are left? If it is some auxiliary utilities, you can create some package like yourapp.utils and put them there. Please provide a little more details.
You should think about the fact that every project consists of modules. Think about toy blocks, that you put together to form your program.
You can imagine a package as a box where you can put another boxes or classes into.
Every package should have a clear responsibility, it could contains sub-packages or classes.
I think it is a nice project structure if you have every class in a specific package, where it is assumed to be.
So If you have structured your project in well considered packages and subpackages no class should be left alone without package. Try to find a good name for a package where it will fit into.
Maybe a "utils" package or "helper" package will a good name for something like that.
Hope I could help :)
Greetings