Here will show one example of doing integration testing taking advantage od the containers technology.
Usually for integration testing some resources need to be allocated for them, such as a database, a messaging system, etc.
With the usage of containers technology we can allocate the required resource for the test quite easy.
In this example I have created a very simple Spring Boot application that interacts with a MySQL database.
For the testing, we would need to insert some data, access to it and so.
For this purpose in our JUnit Test case we can create a MySQL database using Docker, initialize it and use it for our tests. Afterwards, once all our tests are done, the database is destroyed; freeing up the resources.
Here will use Testcontainers library, which I find very useful for this goal.
This example tries to show how to use them not interacting directly to the database container, but using Spring features such as the repositories, autowiring, etc.
Full source code (as a first version to be improved) is located in this GitHub repo:
https://github.com/rafareyeslopez/spring-mysql-testcontainers-demo
Here you can find tips and solutions about different technnologies such as Java, Spring, Kubernetes, Databases... based on my experience working on several software projects.
Friday, November 30, 2018
Wednesday, October 3, 2018
Tmux - Linux
Sometimes when running some scripts on a Linux terminal we can lose the connection when being connected via SSH.
One way to avoid this is unsing the Tmux tool. Many information about this can be found on the Web.
The use case mentioned can be solved using it as if we do the follwoing as example:
tmux new-session -A -s my_session
A new "session" is opened, there you can launch your commands. Even close the SSH terminal (not CTRL+C as would terminate the execution).
If you open again a SSH terminal you can see the existing Tmux sessions.
tmux ls
Also you can reconnect to a session previously created by executing again.
tmux new-session -A -s my_session
To close the session just use the "exit" command.
One way to avoid this is unsing the Tmux tool. Many information about this can be found on the Web.
The use case mentioned can be solved using it as if we do the follwoing as example:
tmux new-session -A -s my_session
A new "session" is opened, there you can launch your commands. Even close the SSH terminal (not CTRL+C as would terminate the execution).
If you open again a SSH terminal you can see the existing Tmux sessions.
tmux ls
Also you can reconnect to a session previously created by executing again.
tmux new-session -A -s my_session
To close the session just use the "exit" command.
Etiquetas:
disconnect,
keep alive,
Linux,
putty,
session,
session close,
ssh
Set up a Jenkins pipeline along with Sonarqueb in Docker
Having the following Dockerfile for Jenkins:
FROM jenkins/jenkins:lts
And this one for Sonarqube:
FROM sonarqube:lts-alpine
Adn the following docker compose file:
jenkins:
container_name: jenkins
build: "jenkins/"
ports:
- "8080:8080"
environment:
- JAVA_OPTS:-Djava.awt.headless=true
volumes:
- /var/jenkins_home
sonarqube:
container_name: sonarqube
image: sonarqube
ports:
- "9000:9000"
links:
- db
environment:
- SONARQUBE_JDBC_URL=jdbc:postgresql://db:5432/sonar
volumes_from:
- plugins
db:
container_name: postgres
image: postgres
volumes_from:
- datadb
environment:
- POSTGRES_USER=sonar
- POSTGRES_PASSWORD=sonar
datadb:
image: postgres
container_name: plugins_postgres
volumes:
- /var/lib/postgresql
command: /bin/true
plugins:
container_name: plugins_sonarqube
image: sonarqube
volumes:
- /opt/sonarqube/extensions
- /opt/sonarqube/lib/bundled-plugins
command: /bin/true
Then we run:
docker-compose -f docker-compose.yml up --build
once it finished we go to IP:8080
Will ask for the first time for the password, for getting it:
docker exec -it jenkins bash
and
cat /var/jenkins_home/secrets/initialAdminPassword
Then we install the suggested plugins
Then will ask to create the first admin user.
Then we go to manage plugins
Blue Ocean
Sonarqube Scanner
Clover
Cobertura
Docker
Jacoco
Maven
PMD
Then we go to sonarqube server on http://IP:9000/
and login using admin / admin
Will ask to generate a token, we do so and then we place it in the next step of setting up jenkins integration with sonarqube
Then we go to configuration of system
In the Global tool configuration:
We would need Clover:
Sonarqube Scanner:
Maven:
Docker:
On Sonarqueb server section:
On Sonarqube we go to administration and in marketplace lets install some plugins we will need:
Checkstyle
Clover
Code smells
Findbugs
Github
PMD
Then on Git section we set it up as follows:
We can use either username and password or token (token is the suggested one)
Then we go back to Sonarqube to set up the quality gates:
First I suggest to create our own quality profile, easiest one is to copy from the Sonarway and then modify it by activating or deactivating the desired rules
Then we set up the quality gate by defining the desired conditions
And then in Jenkins section for Quality gates of Sonarqube
Now is time to create our first Job!
Before that we must ensure that the git repository has everything what we need
As we are using Maven we have to have a pom.xml file in the root of the repository
Also we will do things here using Jenkinsfiles, therefore we need the Jenkinsfile to be place in one of the project folders, in our case we will have it in the parent folder as well. Example of Jenkinsfile:
pipeline {
agent any
tools {
maven 'myMaven'
}
stages {
stage('Initialize') {
steps {
sh '''
echo "PATH = ${PATH}"
echo "M2_HOME = ${M2_HOME}"
'''
}
}
stage('Build') {
steps {
sh 'mvn -B -DskipTests clean package'
}
}
stage('Test') {
steps {
sh 'mvn test'
}
post {
always {
junit '/target/surefire-reports/*.xml'
}
}
}
stage('SonarQube analysis') {
steps {
withSonarQubeEnv('SonarQube Server') {
sh 'mvn clean package test sonar:sonar'
}
}
}
stage("Quality Gate") {
steps {
waitForQualityGate abortPipeline: true
}
}
}
}
One more things, in the pom.xml file we should have in properties something like this:
| <properties> | |
| <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> | |
| <java.version>1.8</java.version> | |
| <hibernate.version>4.3.7.Final</hibernate.version> | |
| <maven.clover2.plugin.version>4.0.6</maven.clover2.plugin.version> | |
| <sonar.clover.reportPath>${project.basedir}/target/site/clover/clover.xml</sonar.clover.reportPath> | |
| </properties> |
and in the build section:
| <build> | |
| <plugins> | |
| <plugin> | |
| <groupId>org.springframework.boot</groupId> | |
| <artifactId>spring-boot-maven-plugin</artifactId> | |
| <!-- Build an executable JAR --> | |
| <configuration> | |
| <archive> | |
| <manifest> | |
| <addClasspath>true</addClasspath> | |
| <classpathPrefix>lib/</classpathPrefix> | |
| <mainClass> idb.mcore.com.boot.BootApplication </mainClass> | |
| </manifest> | |
| </archive> | |
| </configuration> | |
| </plugin> | |
| <plugin> | |
| <groupId>com.atlassian.maven.plugins</groupId> | |
| <artifactId>maven-clover2-plugin</artifactId> | |
| <version>${maven.clover2.plugin.version}</version> | |
| <configuration> | |
| <generateHtml>true</generateHtml> | |
| <generateXml>true</generateXml> | |
| <includesTestSourceRoots>false</includesTestSourceRoots> | |
| <includesAllSourceRoots>true</includesAllSourceRoots> | |
| <excludes> | |
| <exclude>**/*Exception*.java</exclude> | |
| </excludes> | |
| <license>***</license> | |
| </configuration> | |
| </plugin> | |
| <plugin> | |
| <groupId>org.pitest</groupId> | |
| <artifactId>pitest-maven</artifactId> | |
| <version>1.2.4</version> | |
| <configuration> | |
| <outputFormats> | |
| <outputFormat>XML</outputFormat> | |
| </outputFormats> | |
| </configuration> | |
| </plugin> | |
| <!-- JaCoCo configuration --> | |
| <plugin> | |
| <groupId>org.jacoco</groupId> | |
| <artifactId>jacoco-maven-plugin</artifactId> | |
| <version>0.7.9</version> | |
| <executions> | |
| <execution> | |
| <id>default-prepare-agent</id> | |
| <goals> | |
| <goal>prepare-agent</goal> | |
| </goals> | |
| </execution> | |
| <execution> | |
| <id>default-report</id> | |
| <phase>prepare-package</phase> | |
| <goals> | |
| <goal>report</goal> | |
| </goals> | |
| </execution> | |
| </executions> | |
| </plugin> | |
| </plugins> | |
| </build> |
Now we can go to create a new Job. We will use a pipeline:
Once ready we can launch the job. We go to the Blue Ocean view:
And lets run it!
Even if you click on the running command you can see the logs.
Once the pipeline finished with success we would see something like this:
Now we can also analyze the project status on sonarqube:
Subscribe to:
Posts (Atom)