Java overriding classes in jar for integration testing (with maven) - java

I have a java maven project in a jar file (bigfat jar, the whole project in one file). I want to do an integration test on it (first option is blackbox testing, but I will settle for whitebox if it is an easier path).
What I am really interested about is the end-to-end result, however some of the interfaces in the middle are APIs and sockets which are hardcoded inside the jar to communicate with a specific port or with a specific website.
What I want to do is to override the classes inside the jar file that are related to these interfaces, and code them with my model interfaces.
The whole new testing project will not go into production, this is purely for testing purposes.
I am using maven.
Any ideas are more than welcome

Related

What changes do I need to make to my kotlin project to output libraries and not an executable

I have a solution that contains a few different Kotlin projects.
1. Spring framework API project
2. Executable tool that does some database work
3. Client code that serves as a wrapper for the API to be called from other solutions
Right now the Client Code is expecting a main method because I believe it's building as an executable, and I'm not sure why. I wasn't the creator of the project so I don't know what type/settings it was created with.
Are there any changes I can make to the project or perhaps some gradle settings that will output the Client code as a jar of code (instead of libraries) that can then be used in a different solution?
Note: It's important that I don't impact the output types of the Spring api project or the Executable DB tool. Those need to remain the same.
Hope that makes sense!

Properly structuring a Java Spring framework project for multiple web applications

I am working on a project using the Java Spring framework, but I am (even after googling or looking through tutorials) unable to understand how it should be used.
Situation:
The project is(or, will be) made up of 3 separate web applications(for three different uses/target audiences) that uses the same database and to some extent functions and/or classes.
Database/cryptography-related classes and such are in a common folder under the project root, which seems appropriate.
Then there is a folder for gradle, used for starting the program("./gradlew app-one:bootRun"), which I suppose makes sense.
Then, there is a folder for one of the web applications("app-one") with related source code(Controllers, Services, etc.) and whatnot.
Problem:
I am tasked with adding the second application. Is it suppose to be a separate folder in the root directory?(Logically/By framework standards)
If it is not, how do I know what belongs to which application?
Do I need to use separate gradle commands to start each of the three applications? Is that even possible, and is it recommended/efficient/the best way to structure everything?
If you want to use maven,you can create a multi-module maven project with parent pom having all dependency management.A core project(jar) having all core functionality and three web projects(war) for your web modules which depend on this core project.You can start build and run these projects with a bat script from one place only.

Packaging common code for better code reuse in java

I have two java projects that are fairly independent beside the fact that they share a common mysql database.
I wanted to refactor these project and extract everything regarding the common data layer. I am using jOOQ, so most of this layer gets autogenerated in my build. Beside that i then have a few common entity classes that are used in both projects.
what would be the best practice to separate this, so that any change can be done one place and still propagate to both projects? create a third java simple project with the common code? what would you do
I work on a distributed system, and multiple daemons need access to the same Postgres database via jOOQ. Since each daemon is its own Java project, I am in the same boat as you basically.
The solution I've been using is to create a third Java project as a Java Library. If you're using Netbeans you can just include it as a subproject dependency and any changes to the library project can be recompiled into the individual application projects.
One thing of note, you'll need to specify the jOOQ library jars in all 3 projects. In Netbeans its easy to specify a project's library directory, and have multiple projects share these dependencies. Netbeans will copy the dependencies at deployment time.
Edit:
The steps are basically:
create a master layout for system, IE:
/master-project/
/master-project/library
/master-project/software
/master-project/software/daemon1
/master-project/software/daemon2
/master-project/common
/master-project/common/utility1
/master-project/common/utility2
create third-party "library" bundles of {jar,src,docs} under /master-project/library.
create "application" projects under /master-project/software, making sure to tell Netbeans to only use third-party libraries under /master-project/library.
create "library" projects under /master-project/common, making sure to tell NB only to use third-party libraries under /master-project/library.
create a "library" for jOOQ code to be shared, as in step 4.
Each project is responsible for its own compile script (including generating jOOQ code, if desirable), and correctly specifying its dependencies out of /master-project/library, and /master-project/common.

Split test classes from the source classes?

I'm writing tests for plug-ins, now is my question is it better to make an apart test source folder for the test classes or can I put them all in the normal source directory?
Because I think it is better to split the functionality classes from the tests classes. So there can't be mistakes. Also if someones deploy the plug-in into the system, all the classes will deploy except the test classes. Am I right?
Keep the test classes in a separate source folder.
You are right. It's best to have them in a separate source folder. You do not want to deploy these classes when you deploy your plug-in, so it's best to keep them separate. You also don't want these test classes in the same mix when you generate documentation.

Measuring code coverage for selenium tests that reside in separate project

I have two separate java maven projects: one is my web app itself and other one is tellurium+selenium automation tests for my web(I moved these tests to separate projects as their code doesn't really belong to the web app project code and doesn't use java classes of my web app, also I want to reuse some parts of those tests for testing my other web apps). Therefore, project where my tests reside doesn't know anything about my web app, except tellurium/selenium conf files(host name, credentials, browser).
So the question: is there any way to measure code coverage of my web app backend that is invoked by my tellurium/selenium tests that reside in separate project?
Thanks in advance. Any help is highly appreciated.
EMMA or cobetura can instrument your classes so that after the test run they create a coverage report.
http://emma.sourceforge.net/reference/ch02s03.html
<instr>/instr is EMMA's offline class instrumentor. It adds bytecode
instrumentation to all classes found in an instrumentation path that
also pass through user-provided coverage filters. Additionally, it
produces the class metadata file necessary for associating runtime
coverage data with the original class definitions during coverage
report generation.

Categories

Resources