I have a Java application with the GRPC API. And there is in the same repo a Java client library for this application.
I am using Maven as a build system.
How can I test that spans are correctly created and the app will work as I expect (i.e. instrumentation doesn't affect the application's logic)?
I tried to play with the agent for testing, but it seems that it should be configured heavily before being used as I can see in the different tests of Gradle plugins.
I have an idea that I should test this only on the integration level (i.e. set up the whole infrastructure for the tracing) but it would be cool to see the mistakes as early as possible :)
Also, I have plans to add the manual instrumentation to this app, because there is a custom Netty-based transport layer to another application and there is custom scheduling logic based on queues.
Related
I have a Java Spring Boot Application, and I build it with Maven. With
spring-boot-maven-plugin,
I can create fat, executable jar file.
Then I copy it to the remote server and run. But sometimes,
I change only one line or event one word in my code and I had to do whole build/copy step again. I'm sure that I'm doing it wrong, but I couldn't find another way that more efficient (Like capistrano in Rails).
At this point, I'm planning to clone source code to server, push from local, pull from remote, build and run approach. What is the correct (or elegant) way of doing this deployment?
For automatic build and deployment process (continuous integration), you can use Jenkins. Refer this documentation for more details: https://jenkins.io/doc/
I would say it depends where are you trying to do it.
The best and the most agile way to do it for a controlled environment is surely a CI-CD (Continuous Integration and Continuous Deployment) pipelines, which complies-builds-tests-deploys your code against every commit made to the source code BUT it may be too slow to use CI-CD for a development environment where you had like to have a shorter feedback cycle and faster feedback to see how the code is progressing.
However, if you are talking about development environment, I will hit another chord and ask you why to deploy to the external server AT ALL while developing. When you use Spring Boot, which helps you develop a self-contained application, you get the Tomcat Server embedded with it for free. That gives you the choice to run the code anywhere you develop and test to move forward.
A simple maven goal - mvn spring-boot:run can make the code run anywhere you had like.
There is another magical library available in Spring-Boot, known as Devtools, which is meant to support agile developers. The library once in the app classpath, performs hot-swapping of byte-code to auto reload of code into the running application (running locally with embedded Tomcat) as soon there is a saved change. This is one of the coolest gadget that a developer can have.
Use of Spring-Loaded (or JRebel for non spring-boot apps) libraries can also help a developer do hot-swapping of byte code to load changes in running application as soon saved.
I hope it helps.
I'm a developer of a BPM application. Our team has a simple hand-written tool, that allows to mock external systems over JMS and SOAP, also this tool allows us to call our own integrations.
However, we want to use something more extensible and bulletproof for integration testing purposes and Citrus Framework seems like a good alternative, but it is designed primarily to be executed like JUnit/TestNG tests, which is not suitable for the case.
We need an application that runs as a standalone one and allows simple configuration without redeployment.
Is this possible with Citrus Framework?
If not, what approach would you recommend for the purpose?
Thank you!
There is a side project from Citrus called Citrus Simulator that is a standalone simulator for multiple message transports including JMS. The project is available on github: https://github.com/christophd/citrus-simulator
User manual (still under construction) can be found here: https://christophd.github.io/citrus-simulator/
Are you supposed to run automated integration tests against a QA server or are you supposed to somehow start an application server from your tests? Does anyone do option #2? How are you supposed to start an application server from tests?
I'm just running into the dilemma of not knowing where to point my selenium driver to. This is a spring java app.
Are you supposed to run automated integration tests against a QA
server or are you supposed to somehow start an application server from
your tests?
As a practical concept, at least the way I see it, the more your test environment(s) looks like your production environment(s), the better. It means that even hardware, location, operational system, etc, have to be considered.
It all comes down to how much "effort" the project is willing to invest on the quality of the product.
You are supposed to run automated integration tests based on your product and project contexts. There isn't a single and final answer to your question, because there are a lot of variables that have to be considered.
Does anyone do option #2?
Yes, I do use a embedded application server but I only used it for database integration but you can apply that for functional automated testing as well.
How are you supposed to start an application server from tests?
One option is to use embedded containers that you can manage with Maven profiles. I recommend you to follow this Arquillian Getting Started guide to understand how it works, and then you can apply the same concept for Selenium and Spring.
I usually go with option 2 -- I use the Maven Jetty Plugin to start an application server running the webapp (usually under a 'test' profile to swap out certain dependencies like the database) and then run Selenium against the locally hosted application. You can bind the Jetty plugin to pre-integration-tests, and stop it in post-integration-tests.
I typically also include the JaCoCo plugin to instrument the Jetty JVM so that I can check coverage from Selenium-style integration tests.
We're migrating our application into a Java EE container, and looking for tools to use for unit testing (and integration testing) our migrated app.
Our requirements include:
Ad-hoc testing: the ability to run tests manually, on demand (to be used by developers while developing code)
Batch testing: the ability to run a large (and growing) set of tests regularly
In-Container: integration tests that use EJBs as they are deployed in the container
Unit testing: Testing of classes not necessarily inside an EJB context
Nice to have: Simple to set up, integrates with ant/IDE
No requirement to test Servlets/JSPs - only POJOs and EJBs
What are you using to achieve testing in Java EE environment? What technologies/setup have you deployed?
My research have uncovered Cactus and JUnitEE: have you had success setting them up?
We use normal JUnit for both unit tests and integration testing. We switch between the two using a VM argument, and have the tests annotated with markers for direct vs. server. We do have a custom TestSuite class though that finds and runs the tests based on this information, as it was easier and less error prone than manually maintaining which tests to run.
In our case we use Spring remoting to talk to servlets and EJB's (via the servlets), and testing both cases is simply a separate launch configuration within Eclipse.
We used JunitEE a few years ago, but eventually gave up on it in favor of just using JUnit throughout. This enabled us to have developers do all their testing without a server at all and run both unit and what I would call low level integration tests in their IDE. Then we let the build machine run the same integration tests against the same code now deployed in the actual server. This makes the development cycle much faster as we rarely need to run the server and deploy service code.
JUnit(EE) is what every major project($100mil+) I've supported has used. It's really a fantastic tool and knowing how to use it is invaluable when/if you decide to look for other job opportunities.
I supported a government financial system that used no unit testing but after a lot of pushing we finally implemented JUnit. The system I work on now is a large government agency modernization and we use JUnit for all of our unit testing. The two large firms supporting the modernization have essential made JUnit the standard across all of the sub projects. We've got ~200 developers using it without a hitch.
It's quick and easy to set up and once you understand it and you can leverage the features it will demonstrate how invaluable it is.
I am starting a project from scratch using Intersystems Cache. I would like to setup a Continuous Integration Server for the project. Cache has unit test libraries, so the idea is to import source into a test database, build the source, run unit tests in the cache terminal, based on changes in the version control system (ClearCase).
Apart from Cache Objectscript, there will definitely be some java code that needs to be built as well. Other technologies could be added later. So I need a Continuous Integration tool that is not bound to one specific technology and that is easily extendible. I have used CruiseControl for building java solutions in the past, but that has been quite some time ago and I am wondering if no better solution is available since.
What is the best (and hopefully free) Continuous Integration product, that is easiest to extend for different technologies?
I'd recommend looking at Hudson. It's insanely easy to try out as it is delivered as an executable jar. It also supports plugins so it may be better suited to extension and customization. There are also a good deal of very handy plugins for Hudson already out there. Its ClearCase support comes via a plugin. There's even a plugin to start and stop VMWare virtual machines from within your build process which may be of interest depending on how you're planning on handling your database server "needs."
I have built a makeshift Continuous Integration Server in the following screencast: http://www.ensemblisms.com/episodes/2
Raymond Roestenburg!!
I am currently testing a stack for continuous integration of our solution is developed in Caché , the stack I'm testing now includes versioning source code using Git + TortoiseGit (with a plugin called "cache-tort-git "https://github.com/intersystems-ru/cache-tort-git/wiki specific to Caché ) for local versioning and BitBucket for remote versioning.
For continuous integration I'm using the Jenkins (evolution of the Hudson) , with a job that downloads the updated source code and after runs a COS script that does the following tasks:
Compiles all the source code;
Compiles all CSP rules;
Compiles all CSP pages;
Run all unit tests;
Run all integration tests;