Integration tests…they are perfect for testing your data flows. You send some request to your application and can control how data is being processed throughout your application. You see how request is received by your controller, then it’s sent to service, dao or other layers, that you have in your application. Sometimes you don’t want some layer to do real work in Spring. For instance, your dao layer is using some native queries to get data from database, and some embedded database doesn’t support some query syntax. Naturally, you still want to have your integration tests, but without a real call to database. What can we do in this situation ? I’d suggest to mock this dao layer, using mockito. Let’s demonstrate how it works ? ######Project setup I use Spring Initialzr to setup projects, so let’s create a simple Spring Boot application. Code can be found here. ######Project structure ├── README.md ├── build.gradle ├── gradle │ └── wrapper │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradlew ├── gradlew.bat ├── spring-integration-mockito.iml └── src ├── main │ ├── java │ │ └── org │ │ └── springmockito │ │ └── demo │ │ ├── DemoApplication.java │ │ ├── ExampleDao.java │ │ ...
For those of you who worked with spring application without spring boot, and remembers those times, when you had to make your configuration using xml - did you ever question yourself how the magic is done ? For instance, if you had to create a component scan, you had to do <context:component-scan base-package="com.yourpackage.blablabla" /> how it really did this component scan ? ######spring.handlers Answer is simple - if you really would like to know how context or any other spring namespace is working - always start from spring.handlers file. It’s present in each spring jar file, which have some namespaces. The more spring dependencies you add - the more spring.handlers files you will have In case of spring-context jar, you will have something like this http\://www.springframework.org/schema/context=org.springframework.context.config.ContextNamespaceHandler http\://www.springframework.org/schema/jee=org.springframework.ejb.config.JeeNamespaceHandler http\://www.springframework.org/schema/lang=org.springframework.scripting.config.LangNamespaceHandler http\://www.springframework.org/schema/task=org.springframework.scheduling.config.TaskNamespaceHandler http\://www.springframework.org/schema/cache=org.springframework.cache.config.CacheNamespaceHandler So, let’s choose component-scan attribute. ######component-scan component-scan is an attribute of context namespace, so, we need ContextNamespaceHandler /* * Copyright 2002-2012 the original author or authors. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law...
######Embeddable When I was a bit younger, I couldn’t understand why more senior engineers stood for embedding builds as much as it’s possible. For instance, you have a database, and you’re running your integration tests only with in memory databases. It was very unusual for me, why having a working database on your local machine, you’re using some weird in memory things ? The time have passed, and I understand now, that embedding your builds is a good practice, because: It reduce your build time It decouples your build phase from any environments Even if you don’t have any database/thirdparty tool installed on your local machine, your build will finish successfully, and after then you can start installing all required third party instruments. Fongo + NoSQl-Unit By this article I’d like to show how to effectively test your Spring DATA repositories using Fongo - an in-memory implementation. I’m not going to explain how Spring Data works, you can read their documentation here Say, you have following repository package org.example.repository; import org.springframework.data.mongodb.repository.MongoRepository; import org.springframework.data.mongodb.repository.Query; import org.startup.queue.domain.Establishment; import java.util.Optional; public interface SomethingRepository extends MongoRepository<Establishment, String> { Optional<Something> findByCol1(String col1); } Next, test it: package org.example.repository; import com.github.fakemongo.Fongo; import com.lordofthejars.nosqlunit.annotation.UsingDataSet; import com.lordofthejars.nosqlunit.core.LoadStrategyEnum; import...
If you’re interested in reducing interaction with your mouse - then use this program. Link - https://www.spectacleapp.com/
If you want easily locate your terminals - then it’s a good instrument for you
PS - it’s especially useful to move app between your physical monitors. And in case of many Desktops. I found this on their github https://github.com/eczarny/spectacle/issues/15
Preface As some of you may already know, from the last autumn-2015 I’m working as a software engineer in startup company called Upwork, in one of teams. From the time I started working there, I realized, that working on freelance basis is completely different from office work, even if you’re working on a good quality freelance job. Why ? At least, because you cant share some knowledge with your coworkers by cuf of coffee in your lunch time. So I decided to convert my blog to some R&D investigation. That’s why I’d like to warn you, that everything here is just an investigation, which I do on my free time, so don’t take it so critically, if you find something, which you don’t agree with, just comment, and let’s discuss. Technologies are changing every day, and we need to follow the trend, don’t we ? Why containers ? Before I can proceed with explanation in my head what is the definition of container, let’s return to the near part times, where we did everything manually: the dyno age, where it was ok to assemble your proeject war manually, and deploy it to the server in the same way. Then, the...
