Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Explore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely — and automatically — with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
Regression testing is an important step in the release process, to ensure that new code doesn't break the existing functionality. As the codebase evolves, we want to run these tests frequently to help catch any issues early on.
The best way to ensure these tests run frequently on an automated basis is, of course, to include them in the CI/CD pipeline. This way, the regression tests will execute automatically whenever we commit code to the repository.
In this tutorial, we'll see how to create regression tests using Selenium, and then include them in our pipeline using GitHub Actions:, to be run on the LambdaTest cloud grid:
1. Introduction
In application development, the need to perform an update-or-insert operation, also known as “upsert”, is quite common. This operation involves putting a new record into a database table if it doesn’t exist or updating an existing record if it does.
In this tutorial, we’ll learn different approaches to performing update-or-insert operations using Spring Data JPA.
2. Setup
For demo purposes, we’ll use a CreditCard entity:
@Entity
@Table(name="credit_card")
public class CreditCard {
@Id
@GeneratedValue(strategy= GenerationType.SEQUENCE, generator = "credit_card_id_seq")
@SequenceGenerator(name = "credit_card_id_seq", sequenceName = "credit_card_id_seq", allocationSize = 1)
private Long id;
private String cardNumber;
private String expiryDate;
private Long customerId;
// getters and setters
}3. Implementation
We’ll implement update-or-insert using three different approaches.
3.1. Using Repository Method
In this approach, we’ll write a transactional default method in the repository using the save(entity) method, which is inherited from the CrudRepository interface. The save(entity) method inserts the record if it’s new, or it updates the existing entity based on id:
public interface CreditCardRepository extends JpaRepository<CreditCard,Long> {
@Transactional
default CreditCard updateOrInsert(CreditCard entity) {
return save(entity);
}
}We’re passing creditCard to the updateOrInsertUsingReposiotry() method inside the CreditCardLogic class, which either inserts or updates the entity based on entity id :
@Service
public class CreditCardLogic {
@Autowired
private CreditCardRepository creditCardRepository;
public void updateOrInsertUsingRepository(CreditCard creditCard) {
creditCardRepository.updateOrInsert(creditCard);
}
}One important note for this approach is that whether the entity is to be updated or not is decided by id. If we need to find existing records based on another column, such as cardNumber instead of id, then this approach won’t work. In that case, we can use the approaches that we discussed in later sections.
We can write unit tests to verify our logic. First, let’s save some test data into the credit_card table:
private CreditCard createAndReturnCreditCards() {
CreditCard card = new CreditCard();
card.setCardNumber("3494323432112222");
card.setExpiryDate("2024-06-21");
card.setCustomerId(10L);
return creditCardRepository.save(card);
}We’ll use the above-saved CreditCard for the update. Let’s build a CreditCard object for insert:
private CreditCard buildCreditCard() {
CreditCard card = new CreditCard();
card.setCardNumber("9994323432112222");
card.setExpiryDate("2024-06-21");
card.setCustomerId(10L);
return card;
}We’re ready to write our unit test:
@Test
void givenCreditCards_whenUpdateOrInsertUsingRepositoryExecuted_thenUpserted() {
// insert test
CreditCard newCreditCard = buildCreditCard();
CreditCard existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
assertNull(existingCardByCardNumber);
creditCardLogic.updateOrInsertUsingRepository(newCreditCard);
existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
assertNotNull(existingCardByCardNumber);
// update test
CreditCard cardForUpdate = existingCard;
String beforeExpiryDate = cardForUpdate.getExpiryDate();
cardForUpdate.setExpiryDate("2029-08-29");
existingCardByCardNumber = creditCardRepository.findByCardNumber(cardForUpdate.getCardNumber());
assertNotNull(existingCardByCardNumber);
creditCardLogic.updateOrInsertUsingRepository(cardForUpdate);
assertNotEquals("2029-08-29", beforeExpiryDate);
CreditCard updatedCard = creditCardRepository.findById(cardForUpdate.getId()).get();
assertEquals("2029-08-29", updatedCard.getExpiryDate());
}In the above test, we’re asserting both insert and update operations for the updateOrInsertUsingRepository() method.
3.2. Using Custom Logic
In this approach, we write custom logic inside the CreditCardLogic class, which first checks if the given row already exists in the table, and based on the output, it decides to insert or update the record :
public void updateOrInsertUsingCustomLogic(CreditCard creditCard) {
CreditCard existingCard = creditCardRepository.findByCardNumber(creditCard.getCardNumber());
if (existingCard != null) {
existingCard.setExpiryDate(creditCard.getExpiryDate());
creditCardRepository.save(creditCard);
} else {
creditCardRepository.save(creditCard);
}
}As per the above logic, if the cardNumber already exists in the database, then we update that existing entity based on the passed CreditCard object. Otherwise, we insert the passed CreditCard as a new entity in the updateOrInsertUsingCustomLogic() method.
We can write unit tests to verify our custom logic:
@Test
void givenCreditCards_whenUpdateOrInsertUsingCustomLogicExecuted_thenUpserted() {
// insert test
CreditCard newCreditCard = buildCreditCard();
CreditCard existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
assertNull(existingCardByCardNumber);
creditCardLogic.updateOrInsertUsingCustomLogic(newCreditCard);
existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
assertNotNull(existingCardByCardNumber);
// update test
CreditCard cardForUpdate = existingCard;
String beforeExpiryDate = cardForUpdate.getExpiryDate();
cardForUpdate.setExpiryDate("2029-08-29");
creditCardLogic.updateOrInsertUsingCustomLogic(cardForUpdate);
assertNotEquals("2029-08-29", beforeExpiryDate);
CreditCard updatedCard = creditCardRepository.findById(cardForUpdate.getId()).get();
assertEquals("2029-08-29", updatedCard.getExpiryDate());
}3.3. Using Database Built-In Feature
Many databases provide a built-in feature to handle conflict on insert. For example, PostgreSQL provides “ON CONFLICT DO UPDATE” and MySQL provides “ON DUPLICATE KEY”. Using this feature, we can write a follow-up update statement when there is a duplicate key while inserting a record into the database.
An example query would be like this:
String updateOrInsert = """
INSERT INTO credit_card (card_number, expiry_date, customer_id)
VALUES( :card_number, :expiry_date, :customer_id )
ON CONFLICT ( card_number )
DO UPDATE SET
card_number = :card_number,
expiry_date = :expiry_date,
customer_id = :customer_id
""";For testing, we’re using the H2 database, which doesn’t provide an “ON CONFLICT” feature, but instead, we can use a merge query provided by the H2 database. Let’s add the merge logic inside the CreditCardLogic class:
@Transactional
public void updateOrInsertUsingBuiltInFeature(CreditCard creditCard) {
Long id = creditCard.getId();
if (creditCard.getId() == null) {
BigInteger nextVal = (BigInteger) em.createNativeQuery("SELECT nextval('credit_card_id_seq')").getSingleResult();
id = nextVal.longValue();
}
String upsertQuery = """
MERGE INTO credit_card (id, card_number, expiry_date, customer_id)
KEY(card_number)
VALUES (?, ?, ?, ?)
""";
Query query = em.createNativeQuery(upsertQuery);
query.setParameter(1, id);
query.setParameter(2, creditCard.getCardNumber());
query.setParameter(3, creditCard.getExpiryDate());
query.setParameter(4, creditCard.getCustomerId());
query.executeUpdate();
}In the above logic, we execute a merge query using the native query provided by entityManager.
Now, let’s write the unit test to verify the results:
@Test
void givenCreditCards_whenUpdateOrInsertUsingBuiltInFeatureExecuted_thenUpserted() {
// insert test
CreditCard newCreditCard = buildCreditCard();
CreditCard existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
assertNull(existingCardByCardNumber);
creditCardLogic.updateOrInsertUsingBuiltInFeature(newCreditCard);
existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
assertNotNull(existingCardByCardNumber);
// update test
CreditCard cardForUpdate = existingCard;
String beforeExpiryDate = cardForUpdate.getExpiryDate();
cardForUpdate.setExpiryDate("2029-08-29");
creditCardLogic.updateOrInsertUsingBuiltInFeature(cardForUpdate);
assertNotEquals("2029-08-29", beforeExpiryDate);
CreditCard updatedCard = creditCardRepository.findById(cardForUpdate.getId()).get();
assertEquals("2029-08-29", updatedCard.getExpiryDate());
}4. Conclusion
In this article, we discussed different approaches to performing update or insert operations in Spring Data JPA. We implemented these approaches along with verification using unit tests. While each database does provide some out-of-the-box features for handling upsert, implementing custom logic in Spring Data JPA on top of upsert based on the id column isn’t that complex.
