What Not To Do During Interviews

One of the biggest mistakes companies make during interviews is asking shallow technology checklist questions. Questions such as “Have you used Spring Boot?”, “Do you know React?”, or “Have you worked with Kubernetes?” reveal almost nothing about actual engineering capability. A candidate may have used a technology for years without deeply understanding it, while another candidate may have learned it recently but understands the underlying engineering concepts far better.

Similarly, asking purely theoretical questions like:

• What are the SOLID principles?
• What is Dependency Injection?
• What is DRY?

often tests memorization rather than engineering judgment. Many candidates can recite textbook definitions perfectly while failing to apply those principles in real systems.

Software engineering is ultimately about implementation trade-offs, maintainability, debugging, testing, and collaboration under constraints — not theory recitation.

Another questionable practice is over-reliance on online coding assessments and algorithm platforms such as LeetCode. While algorithms and data structures do matter for certain domains, most real-world engineering work does not involve solving obscure graph problems or reversing binary trees within 20 minutes under pressure.

Real engineers work with existing codebases, debug production issues, write tests, review pull requests, and improve maintainability. Excessive emphasis on puzzle-solving often filters for candidates who are good at interview preparation rather than candidates who are good at engineering.

Interviews should resemble actual work as closely as possible.

Another common mistake is conducting interviews in an adversarial manner, where interviewers attempt to “catch” candidates making mistakes instead of understanding how they think and collaborate. Good interviews should evaluate reasoning, communication, adaptability, and engineering maturity — not create artificial stress.

What Categories Should Be Tested

The first category should always focus on the actual languages, frameworks, and technologies used in the real project. If the project uses Java, Spring Boot, React, GraphQL, or Kubernetes, then the interview should naturally revolve around realistic scenarios involving those technologies.

Instead of asking abstract trivia questions, use examples based on actual engineering problems the team encounters.

One of the best approaches is to use a simplified subset of the real project codebase. Take a real function or service that contains meaningful complexity and ask the candidate to work with it.

The code could intentionally contain:

• Poor naming
• Duplicated logic
• Tight coupling
• Missing error handling
• Performance problems
• Hidden bugs

Ask the candidate how they would improve the code, refactor it, debug it, or redesign parts of it. This evaluates practical engineering ability far more effectively than theoretical questions.

It also reveals how candidates think about:

• Readability
• Maintainability
• Scalability
• Testing
• Engineering trade-offs

Automated Testing Matters

Another highly important category is automated testing. Many engineers claim to value testing, but interviews rarely evaluate whether they can actually write good tests.

Give candidates a realistic piece of code and ask them to write unit tests for it. However, the goal should not be writing tests purely for coverage numbers.

Good engineers understand that tests should validate:

• Behavior
• Business logic
• Edge cases
• Failure scenarios

rather than implementation details.

Strong candidates usually identify meaningful assertions naturally. They also understand when mocking is appropriate and when excessive mocking makes tests brittle and meaningless.

Testing ability is often one of the strongest indicators of engineering maturity.

Test Adaptability and Learning Ability

Another category that is frequently overlooked is adaptability and learning capability.

Technology changes constantly, and engineers will inevitably encounter unfamiliar tools, frameworks, or architectures. Instead of only testing existing knowledge, introduce the candidate to something they have not used before and ask how they would approach learning and implementing it.

For example, ask questions such as:

• What steps would you take to understand it?
• How would you validate whether it is suitable?
• What documentation or resources would you look for?
• How would you prototype or test it?
• What would you do if your initial approach failed?
• How would you troubleshoot issues during implementation?

This evaluates problem-solving ability, resourcefulness, and engineering mindset far better than memorized answers.

Strong engineers are not defined by knowing everything already — they are defined by how effectively they can learn, adapt, debug, and deliver solutions when facing unfamiliar problems.

Final Thoughts

A good software engineering interview should mirror actual engineering work. It should evaluate how candidates think, communicate, debug, test, improve systems, and adapt to change.

The goal is not to find candidates who can memorize definitions or solve artificial puzzles under pressure.

The goal is to identify engineers who can contribute meaningfully to real systems, collaborate effectively with teams, and continuously improve both the codebase and the engineering culture around them.

Let’s break down why unit tests matter, and why your goal should be near-total coverage, only making exceptions when absolutely necessary.

✅ What Are Unit Tests, Really?

A unit test is a piece of code that verifies the behavior of the smallest testable part of your application — typically a function, method, or class — in isolation. It checks one thing, with no external dependencies (like databases, networks, or file systems). It tells you immediately if a unit of code behaves as expected under certain conditions.

🏎️ Unit Tests Are Like Seat Belts in a Racing Car

Imagine a professional race car driver about to take on a high-speed track. Without a seat belt, even the best driver in the world will instinctively hold back. Why? Because there’s no margin for error. One slip, and the consequences are catastrophic.

Now add a seat belt — snug, secure, and crash-tested. Suddenly, the driver gains confidence. They can take sharper turns, go faster, and push the limits of the car, knowing they have a safety mechanism in place.

Unit tests are that seat belt for your code.

They don’t stop accidents, but they reduce the cost of failure. They give you the confidence to move faster, refactor aggressively, and experiment — because if something goes wrong, your tests will catch it before anyone else does.

🎯 Unit Tests Are About Quality — Not Just Safety

In project management, quality is defined as:

“The degree to which a set of inherent characteristics of the project deliverables and processes fulfill requirements.”

This definition highlights that quality is not subjective — it’s measured by how well a product meets functional and non-functional requirements.

Unit tests enforce this quality.

They verify that each component behaves as expected, ensuring your deliverables meet the defined requirements at the micro level. A system without unit tests may still compile and run — but you have no guarantee that it does the right thing. Without tests, you’re relying on hope instead of proof.

In this light, unit testing isn’t just a technical practice — it’s a quality management practice. And just like quality in manufacturing or construction, it’s non-negotiable if you want reliable results.

🔍 Why Unit Testing Is Non-Negotiable

1. Prevents Bugs Early Unit tests catch regressions and logical errors before your application ever reaches QA or production. Finding bugs early is not only cheaper — it avoids fire-fighting and user complaints later on.

2. Supports Confident Refactoring With good test coverage, you can refactor with peace of mind. Like a seat belt, your tests give you assurance that you won’t crash the system while optimizing or rewriting code.

3. Improves Design Testable code is often better designed. It’s more modular, has fewer side effects, and adheres to principles like Single Responsibility and Dependency Injection. Writing tests forces you to think about your architecture.

4. Documents Behavior Tests are live documentation that explain how a function is supposed to behave — more accurate and useful than outdated wiki pages or code comments.

5. Speeds Up Development Over Time At first, writing tests might seem like overhead. But with a comprehensive test suite, you can make changes quickly and ship features faster — because you’re not constantly worried about breaking things.

🎯 Why Aim for 100% (or Near-100%) Test Coverage?

Striving for 100% unit test coverage is less about vanity metrics and more about discipline and completeness. Every uncovered line of code is a potential point of failure. Here’s why that near-total coverage matters:

• Uncovered Code Is Untested Code If a line isn’t covered by any test, it means you’ve never verified how it behaves. That’s a risk, especially when onboarding new team members or making large-scale changes.

• Edge Cases Live in the Shadows Most bugs don’t happen in the “happy path.” Reaching high coverage forces you to consider unusual inputs, boundary conditions, and failure scenarios.

• Legacy Code Is Harder to Modernize Without It If you ever plan to rewrite, modularize, or extract services from a legacy system, having thorough tests makes that possible without breaking production.

🚫 When 100% Isn’t Practical

There are times when 100% coverage is not worth the tradeoff:

Auto-generated code (e.g., by frameworks or tools)

Trivial boilerplate (e.g., simple getters/setters or toString() methods)

Low-level integration glue that’s better tested via integration or end-to-end tests

Code with external dependencies where mocking is more complex than value-add

The key is to be intentional about what’s not tested. You should be able to explain why, not just because it was too hard or forgotten.

💡 Best Practices for Achieving High Coverage

Test as you go: Don’t wait until the end. Write tests alongside your code (TDD, or at least test-after).

Use mocking wisely: Mock external systems, but not your own business logic.

Use coverage tools: Tools like JaCoCo, Istanbul, or Coverage.py help visualize what’s missing.

Review test quality, not just quantity: 100% coverage with poor assertions is worse than 80% with meaningful tests.

🧠 Final Thoughts

High unit test coverage isn’t about checking a box — it’s about building a foundation of quality and confidence. It enables faster delivery, fewer bugs, and sustainable development. Like a racing seat belt, it lets you move fast and take risks — safely.

And when viewed through the lens of project management, unit tests aren’t just a technical safeguard. They’re a quality assurance measure. They help ensure that what you build actually fulfills the requirements — both stated and implied.

You don’t need to dogmatically hit 100%, but you should aim for it as the norm, not the exception. If a line isn’t worth testing, ask why it’s there at all.

When using Spring Data JPA and Hibernate, you might encounter intermittent test failures even when your logic seems correct. Consider the following typical test case implementation:

@Test
void findAllByModifiedAtAfter() {
    // Setup
    Book book = Book.builder().id("1").title("Hibernate Basics").build();
    bookRepository.save(book);

    Book savedBook = bookRepository.findById("1").orElseThrow();
    LocalDateTime originalModifiedAt = savedBook.getModifiedAt();

    savedBook.setTitle("Hibernate Advanced");
    bookRepository.save(savedBook);

    // Execute
    List<Book> result = bookRepository.findAllByModifiedAtAfter(originalModifiedAt);

    // Verify
    assertThat(result, hasSize(1));
    assertThat(result.getFirst().getId(), is("1"));
}

At first glance, the test looks correct—you save an entity, modify it, and then query for entities modified after the original timestamp. However, this test fails intermittently. Why?

🔎 Why This Test Fails Intermittently

Spring and Hibernate optimize performance by aggregating save operations within a transaction. This is part of Hibernate’s write-behind caching strategy, where changes to entities are held in memory and only written to the database at transaction commit or when flush() is called.

1️⃣ Hibernate’s Delayed Execution

• When bookRepository.save() is called, Hibernate does not immediately execute the INSERT or UPDATE statements.
• It defers them until a flush, query, or transaction commit, which can cause @LastModifiedDate to appear unchanged in the current session.

2️⃣ @LastModifiedDate Might Not Update Immediately

• Hibernate updates fields like @LastModifiedDate only when it detects a change and flushes it to the database.
• Without explicitly flushing or committing the transaction, the update may not be persisted by the time you query for it.

✅ The Solution: Flush Immediately and Isolate the Transaction

To fix this issue, we must:

• Flush after each save to force Hibernate to persist changes immediately.
• Ensure that at least one field is modified before saving again.
• Use separate transactions to isolate each save, preventing Hibernate from aggregating operations.

📦 Book Entity with Audit Fields

@Entity
@EntityListeners(AuditingEntityListener.class)
@Data
@Builder
@AllArgsConstructor
@NoArgsConstructor
public class Book {

    @Id
    private String id;

    private String title;

    @CreatedDate
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime modifiedAt;
}

✅ Reliable Test Case That Always Passes

@Test
void findAllByModifiedAtAfter() {
    // Setup
    Book book = Book.builder().id("1").title("Hibernate Basics").build();
    saveWithTransaction(book);
    entityManager.flush(); // ✅ Forces immediate INSERT

    Book savedBook = getBook("1");
    LocalDateTime originalModifiedAt = savedBook.getModifiedAt();

    savedBook.setTitle("Hibernate Advanced"); // ✅ Ensure change is detected
    saveWithTransaction(savedBook);
    entityManager.flush(); // ✅ Ensures update is persisted

    // Execute
    List<Book> result = findModifiedAfter(originalModifiedAt);

    // Verify
    assertThat(result, hasSize(1));
    assertThat(result.getFirst().getId(), is("1"));
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
void saveWithTransaction(Book book) {
    bookRepository.save(book);
    entityManager.flush();   // Force DB write
    entityManager.clear();   // Clear Hibernate cache
}

@Transactional(readOnly = true)
Book getBook(String id) {
    return bookRepository.findById(id).orElseThrow();
}

@Transactional(readOnly = true)
List<Book> findModifiedAfter(LocalDateTime threshold) {
    return bookRepository.findAllByModifiedAtAfter(threshold);
}

🔹 Key Fixes That Prevent Aggregation Issues

1. Immediate Execution with flush()
   • Ensures Hibernate writes changes to the DB immediately instead of batching.
2. Modifying a Field to Trigger @LastModifiedDate
   • Hibernate only updates the field if a change is detected.
3. Clearing the Persistence Context
   • Forces Hibernate to reload from the database rather than using cached entities.
4. Using @Transactional(readOnly = true) for Queries
   • Ensures fresh, non-stale data is read without caching interference.

🧠 Should You Even Write This Test?

In most cases, writing a test just to check whether @LastModifiedDate is updated is unnecessary. This auditing behavior is already provided and tested by Spring Data JPA. If you’ve properly configured auditing (via @EnableJpaAuditing and @EntityListeners(AuditingEntityListener.class)), then you can trust the framework to manage those fields—just like you wouldn’t write a test to verify that @GeneratedValue creates unique IDs.

You should only write such a test if your business logic depends on custom behavior involving modification timestamps—for example, filtering modified entities manually or triggering downstream processes.

🚀 Final Thoughts

Yes, Hibernate aggregates save operations by default due to write-behind caching in the persistence context. This can lead to unreliable tests if you rely on immediate updates to @LastModifiedDate.

To write a reliable test:

• Use flush() to force Hibernate to write changes
• Modify at least one field before saving
• Clear the persistence context if needed
• Separate your save operations into isolated transactions

That way, you ensure deterministic behavior—and your tests will pass consistently. 🚀

Instancio is particularly a life-saver when dealing with objects that have a large number of fields. For example, consider a Customer class with over 20 fields, including nested objects. Manually mocking such an object can quickly become cumbersome and error-prone. With Instancio, you can generate such objects with ease:

@Test
public void generateComplexObject() {
    Customer customer = Instancio.create(Customer.class);
    System.out.println(customer);
}

This simple code snippet creates an instance of Customer with all its fields populated, including nested objects, eliminating the need for manual setup.

What is Instancio?

Instancio is a flexible and powerful library that automates the creation of Java objects with populated fields. It supports complex object graphs and works seamlessly with both primitive and custom types. You can generate realistic test data with just a few lines of code, making it an excellent tool for unit and integration testing in Spring Boot.

Key Features of Instancio

• Automatic Object Creation: Instancio automatically creates objects and populates their fields.

• Customizable Rules: You can specify generation rules for specific fields or types.

• Support for Nested Objects: Generate complex object graphs effortlessly.

• Integration with JUnit and TestNG: Easily integrate Instancio into your test framework.

• Fluent API: The library offers a user-friendly API for customizing object creation.

Setting Up Instancio in a Spring Boot Project

To start using Instancio, add the following dependency to your pom.xml file if you’re using Maven:

<dependency>
    <groupId>org.instancio</groupId>
    <artifactId>instancio-core</artifactId>
    <version>2.0.0</version>
    <scope>test</scope>
</dependency>

For Gradle, add:

testImplementation 'org.instancio:instancio-core:2.0.0'

Basic Usage

Generating a Simple Object

Suppose you have a User class with fields like id, name, and email. You can use Instancio to generate a User instance as follows:

import org.instancio.Instancio;

@Test
public void generateSimpleObject() {
    User user = Instancio.create(User.class);
    System.out.println(user);
}

Instancio automatically populates the fields of the User class with realistic values, such as random strings for name and email.

Generating a List of Objects

To generate a collection of objects, use the Instancio.ofList() method:

@Test
public void generateListOfObjects() {
    List<User> users = Instancio.ofList(User.class).size(10).create();
    users.forEach(System.out::println);
}

This creates a list of 10 User objects with populated fields.

Customizing Object Generation

Setting Specific Values

You can customize object generation by setting specific values for certain fields:

@Test
public void customizeFieldGeneration() {
    User user = Instancio.of(User.class)
            .set(field(User::getName), "John Doe")
            .set(field(User::getEmail), "john.doe@example.com")
            .create();
    System.out.println(user);
}

Ignoring Fields

If you want to exclude certain fields from being populated, you can do so with the ignore() method:

@Test
public void ignoreFields() {
    User user = Instancio.of(User.class)
            .ignore(field(User::getPassword))
            .create();
    System.out.println(user);
}

Generating a Past Date

Instancio provides a generate() method that allows for advanced customizations, such as generating dates in the past. For example:

@Test
public void generatePastDate() {
    User user = Instancio.of(User.class)
            .generate(field(User::getBirthDate), gen -> gen.temporal().localDate().past(LocalDate.now().minusYears(1)))
            .create();
    System.out.println(user.getBirthDate());
}

In this example, the birthDate field is generated as a date from the past year.

Generating a String in Microsoft JSON Date Format

To generate a string representing a date in the Microsoft JSON date format, you can use the generate() method with a custom generator:

@Test
public void generateMicrosoftJsonDateFormat() {
    User user = Instancio.of(User.class)
            .generate(field(User::getDateString), gen -> gen.string().from(() -> {
                Date date = Date.from(LocalDate.now().atStartOfDay(ZoneId.systemDefault()).toInstant());
                return "/Date(" + date.getTime() + ")/";
            }))
            .create();
    System.out.println(user.getDateString());
}

In this example, the dateString field is generated as a string in the Microsoft JSON date format (e.g., /Date(1672531200000)/).

Using Instancio in Spring Boot Tests

Integration with Spring Boot

Instancio can be used in unit and integration tests in a Spring Boot project. Here is an example using Instancio with Spring Boot’s testing framework:

@SpringBootTest
public class UserServiceTest {

    @Autowired
    private UserService userService;

    @Test
    public void testCreateUser() {
        User user = Instancio.of(User.class)
                .set(field(User::getName), "Jane Doe")
                .set(field(User::getEmail), "jane.doe@example.com")
                .create();

        userService.save(user);

        User retrievedUser = userService.findById(user.getId());
        assertEquals("Jane Doe", retrievedUser.getName());
        assertEquals("jane.doe@example.com", retrievedUser.getEmail());
    }
}

Mocking with Instancio

When writing unit tests with mocking frameworks like Mockito, you can use Instancio to generate mock data:

@Test
public void testWithMockedRepository() {
    User user = Instancio.create(User.class);

    when(userRepository.save(any(User.class))).thenReturn(user);

    User savedUser = userService.save(new User());
    assertNotNull(savedUser);
}

Advantages of Using Instancio

• Time-Saving: Automatically generating test data saves time and effort.

• Improved Test Quality: Realistic and diverse data leads to better test coverage.

• Flexibility: Customization options allow you to control the generated data.

• Ease of Use: The fluent API makes Instancio easy to integrate and use.

Conclusion

Instancio is a powerful tool for generating test data in Spring Boot projects. By automating object creation, it reduces the time and effort needed to write effective tests, allowing developers to focus on building robust applications. Whether you’re writing unit tests or integration tests, Instancio can streamline your testing process and enhance the quality of your tests.

ReactiveSecurityContextHolder is a utility class in Spring Security’s reactive stack, designed to work with Project Reactor, a reactive programming library. It provides non-blocking access to the security context, holding the current user’s authentication details in a Mono. This class is akin to SecurityContextHolder in traditional, blocking Spring Security but tailored for reactive applications where blocking operations are discouraged or even disallowed. The `ReactiveSecurityContextHolder` operates within the ReactorContext, which carries contextual information in a reactive application. In practice, this enables the retrieval and manipulation of security context information (such as user authentication) seamlessly across different stages of a reactive pipeline.

Example to get the security context with ReactiveSecurityContextHolder

import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.ReactiveSecurityContextHolder;
import org.springframework.security.core.userdetails.UserDetails;
import reactor.core.publisher.Mono;

public Mono<String> getUserDetails() {
    return ReactiveSecurityContextHolder.getContext()
        .map(securityContext -> {
            Authentication authentication = securityContext.getAuthentication();
            UserDetails userDetails = (UserDetails) authentication.getPrincipal();
            return "User: " + userDetails.getUsername();
        });
}

Example to save the security context with ReactiveSecurityContextHolder

import org.springframework.security.authentication.UsernamePasswordAuthenticationToken;
import org.springframework.security.core.context.SecurityContextImpl;
import org.springframework.security.core.context.ReactiveSecurityContextHolder;
import reactor.core.publisher.Mono;

public Mono<Void> setCustomSecurityContext(String username, String role) {
    UsernamePasswordAuthenticationToken authentication = 
        new UsernamePasswordAuthenticationToken(username, null, List.of(new SimpleGrantedAuthority(role)));
    SecurityContextImpl securityContext = new SecurityContextImpl(authentication);

    return Mono.deferContextual(context -> 
        ReactiveSecurityContextHolder.withSecurityContext(Mono.just(securityContext)))
        .then();
}

Reactive Web Filters are often used for cross-cutting concerns like logging, authentication, and authorization. In scenarios where you need to intercept and modify the SecurityContext in a filter, you can use ReactiveSecurityContextHolder as shown below:

import org.springframework.web.server.WebFilter;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

public class CustomSecurityContextFilter implements WebFilter {
    
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
        return ReactiveSecurityContextHolder.getContext()
            .flatMap(securityContext -> {
                // Modify or inspect security context as needed
                return chain.filter(exchange).contextWrite(ReactiveSecurityContextHolder.withSecurityContext(Mono.just(securityContext)));
            });
    }
}

Practical Tips

• Avoid Blocking Calls: Ensure that you only use ReactiveSecurityContextHolder within reactive flows, avoiding any blocking operations as they could lead to performance issues in reactive applications.
• Context Propagation: Use contextWrite to propagate security context changes within the reactive pipeline, especially if you’re creating custom authentication mechanisms or performing role checks.
• Fallback Mechanisms: Always handle cases where the security context might be absent, especially in routes that are not secured, to avoid NullPointerExceptions.

ReactiveSecurityContextHolder is a powerful tool for managing security contexts in Spring reactive applications, enabling access to authentication details across non-blocking, asynchronous streams. By following the patterns and examples above, you can confidently manage security in your reactive applications, ensuring a seamless and efficient user authentication experience.

Understanding ReactiveSecurityContextHolder and its usage will help you harness the full power of Spring Security’s reactive capabilities, making it an essential part of any developer’s toolkit in reactive programming.

And to confirm that the profile is really activated, check that the log The following 1 profile is active: followed by the activated profile name. Example - [demo] [ main] com.example.demo.DemoApplication : The following 1 profile is active: "dev".

Step 1: Configure the Artifacts Feed in the Main Project To access the artifact from the Common project, we need to add the Common-Feed as a repository in the Main project’s pom.xml. This will ensure Maven can resolve dependencies from this feed.

In the Main project’s pom.xml, add the following repository configuration:

<repositories>
    <repository>
        <id>Common-Feed</id>
        <url>https://pkgs.dev.azure.com/ORGANIZATION/PROJECT/_packaging/Common-Feed/maven/v1</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
    </repository>
</repositories>

Replace ORGANIZATION and PROJECT with the relevant names in your Azure DevOps organization.

Step 2: Add the Common Dependency Next, add a dependency in the Main project’s pom.xml to specify the artifact from the Common project. Ensure that the artifactId, groupId, and version match those used in the Common project’s pom.xml.

<dependencies>
    <dependency>
        <groupId>com.yourcompany.common</groupId>
        <artifactId>common-artifact</artifactId>
        <version>1.0.0</version>
    </dependency>
</dependencies>

After each update to the Common project, increment the version number to pull the latest changes.

Step 3: Update the Pipeline for Main In the Main project pipeline, we’ll use MavenAuthenticate@0 to handle authentication for the feed and ensure Maven can access our internal artifact.

Here’s the updated pipeline YAML for the Main project, which will download and use the Common dependency from the Artifacts Feed.

trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - checkout: self

  - task: JavaToolInstaller@0
    inputs:
      versionSpec: '11'
      jdkArchitectureOption: 'x64'
      jdkSourceOption: 'PreInstalled'

  # Authenticate with the Common-Feed
  - task: MavenAuthenticate@0
    inputs:
      artifactsFeeds: Common-Feed

  # Build and test the Main project
  - task: Maven@4
    inputs:
      mavenPomFile: 'pom.xml'
      goals: 'clean install'
      publishJUnitResults: true
      testResultsFiles: '**/surefire-reports/TEST-*.xml'
      javaHomeOption: 'JDKVersion'
      jdkVersionOption: '1.11'
      mavenVersionOption: 'Default'
      mavenAuthenticateFeed: false
      effectivePomSkip: false
      sonarQubeRunAnalysis: false

Step 4: Verify the Dependency Resolution After setting up the pipeline and pom.xml, run the pipeline in Azure DevOps. Maven should authenticate with Common-Feed automatically and retrieve the Common artifact. You should see the dependency being resolved in the pipeline logs during the build step.

Managing Artifact Versions As noted previously, remember to update the version in pom.xml each time there’s a change in the Common project to reflect the latest updates.

Summary By setting up an Artifacts Feed in Azure DevOps and using MavenAuthenticate@0, we have created a simple way for projects within an organization to share and manage dependencies without relying on public repositories. This setup is scalable and secure for any size of enterprise or startup, leveraging Azure DevOps’ integrated artifact management capabilities.

In a simple example in my Azure DevOps project, I have 2 repositories - Common and Main. Common is a dependency in Main. To begin, I will create a Artifacts Feed for my artifacts, assigned with the relevant visibility, and calling it Common-Feed.

So in my pipeline for Common, I will call mvn deploy to deploy the jar file to this feed, so that it can be consumed by Main. Usually, this will mean updating the settings.xml in the Maven Home, so I’ll need some additional tasks in my pipeline to either get the file from the Secured Files and add it to the maven options for my deployment task. However, Azure DevOps has a handy shortcut to achieve that without the dirty work.

Before we run the deploy task, we’ll need to call the MavenAuthenticate@0 task to do the authentication automatically.

- task: MavenAuthenticate@0
  inputs:
    artifactsFeeds: Common-Feed

This step will update the settings.xml for us. Make sure to set the artifactsFeed to the name of the feed created earlier.

Then in our deploy task, we set the deployment location to the url of the Artifacts Feed we created too, and make sure the property mavenAuthenticateFeed is set to false.

- task: Maven@4
  inputs:
    mavenPomFile: 'pom.xml'
    goals: 'deploy'
    options: '-Dmaven.test.skip=true -DaltDeploymentRepository=Common-Feed::default::https://pkgs.dev.azure.com/ORGANIZATION/PROJECT/_packaging/Common-Feed/maven/v1'
    javaHomeOption: 'JDKVersion'
    jdkVersionOption: '1.11'
    mavenAuthenticateFeed: false

Also do note thate the id of the altDeploymentRepository is the name of the feed too, in our case, it is Common-Feed, as mentioned earlier.

Then, we also need to add this new Common-Feed to our pom.xml as a repository.

<repositories>
    <repository>
        <id>Common-Feed</id>
        <url>https://pkgs.dev.azure.com/ORGANIZATION/PROJECT/_packaging/Common-Feed/maven/v1</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
    </repository>
</repositories>

The full azure-pipelines.xml is as below.

trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - checkout: self
  - task: JavaToolInstaller@0
    inputs:
      versionSpec: '11'
      jdkArchitectureOption: 'x64'
      jdkSourceOption: 'PreInstalled'
  - task: MavenAuthenticate@0
    inputs:
      artifactsFeeds: Common-Feed
  - task: Maven@4
    inputs:
      mavenPomFile: 'pom.xml'
      goals: 'clean install'
      publishJUnitResults: true
      testResultsFiles: '**/surefire-reports/TEST-*.xml'
      javaHomeOption: 'JDKVersion'
      jdkVersionOption: '1.11'
      mavenVersionOption: 'Default'
      mavenAuthenticateFeed: false
      effectivePomSkip: false
      sonarQubeRunAnalysis: false
- task: Maven@4
  inputs:
    mavenPomFile: 'pom.xml'
    goals: 'deploy'
    options: '-Dmaven.test.skip=true -DaltDeploymentRepository=Common-Feed::default::https://pkgs.dev.azure.com/ORGANIZATION/PROJECT/_packaging/Common-Feed/maven/v1'
    javaHomeOption: 'JDKVersion'
    jdkVersionOption: '1.11'
    mavenAuthenticateFeed: false

So after the feed runs, it will deploy an artifact to the Artifacts Feed, and it will be visible in the Artifacts tab in Azure DevOps.

Do note that after the first artifact is available in the Artifacts Feed, you will need to update the version number of the project in the pom file every time you update the code.

Turns out according to this article, git by default uses the “linux” crypto backend, which is openssl, and I don’t have openssl in my local machine. To fix the issue, I just have to amend the git configuration http.sslbackend to use Windows built-in networking layer - SChannel.

git config --global http.sslbackend schannel

Doing so will use the Windows certificate storage mechanism when required. Now when I try to push again, I am through!

GraphQL pretty much handles validation issues for us, like the screenshot below. We missed out a required field, and graphql provides the appropriate message for us automatically.

However, if the exception is due to the internal execution to do the mutation or query of the data, graphql will only give an Internal Error, without much information.

For example, in the update function below, the program will first get the repository to find the product, before updating the product with the fields from the updatedProduct and save it back in the repository.

public Mono<Product> updateProduct(String id, Product updatedProduct){
    return productRepository.findById(id)
            .switchIfEmpty(Mono.error(new IllegalArgumentException("Product not found")))
            .flatMap(product -> {
                product.setName(updatedProduct.getName());
                product.setDescription(updatedProduct.getDescription());
                product.setPrice(updatedProduct.getPrice());
                product.setCategory(updatedProduct.getCategory());
                return productRepository.save(product);
            });
}

If the product id is not found in the repository, it should return a Mono error, encapsulating an IllegalArgumentException with the appropriate error message - Product not found.

However, this information is not passed on to the graphql, like what we saw in the screenshot earlier. The message is intentionally opaque to avoid leaking implementation details. Nevertheless, we can handle this error such that it can return the appropriate message to the client.

To handle the exceptions for only with the specific controller itself, we can add the handle function with the @GraphQlExceptionHandler, as described in the documentation.

@Controller
@Slf4j
public class ProductController {

    ...

    @GraphQlExceptionHandler
    public GraphQLError handle(@NonNull Throwable ex, @NonNull DataFetchingEnvironment environment){
        return GraphQLError
                .newError()
                .errorType(ErrorType.BAD_REQUEST)
                .message(ex.getMessage())
                .path(environment.getExecutionStepInfo().getPath())
                .location(environment.getField().getSourceLocation())
                .build();
    }
}

In the above function, we got the Throwable and DataFetchingEnvironment to return the error message and the path and location of where the exception occurred, returning a GraphQLError to the client.

Running the same function again, now we get a more meaningful message. Do note that for the above method, it only handles exceptions from the ProductController class.

Alternatively, we can also create an extension of the DataFetcherExceptionResolverAdapter as a fallback to handle exceptions not caught by the respective controllers, as described in the documentation.

@Component
public class CustomExceptionResolver extends DataFetcherExceptionResolverAdapter {
    @Override
    protected GraphQLError resolveToSingleError(@NonNull Throwable ex, @NonNull DataFetchingEnvironment env){
        return GraphqlErrorBuilder.newError()
                .errorType(ErrorType.BAD_REQUEST)
                .message(ex.getMessage())
                .path(env.getExecutionStepInfo().getPath())
                .location(env.getField().getSourceLocation())
                .build();
    }
}

We can test that it works in the following integration test. Here, after executing the graphql, we call the errors() and expect() to check on the error message. Without the above implementation, the test will fail because it would get in Internal Error instead.

@Test
@Order(5)
void updateProduct_invalidProduct(){
    this.httpGraphQlTester
            .document("""
                    mutation {
                        updateProduct(
                            id: "123",
                            updatedProduct: {
                                name: "Pilot G1 Pen",
                                description: "Best selling gel-based ball point pen",
                                price: 1.80
                                category: "Stationery"
                            }
                        ){
                            id
                            name
                            description
                            price
                            category
                        }
                    }
                    """)
            .execute()
            .errors()
            .expect(error -> Objects.equals(error.getMessage(), "Product not found"));
}

A working copy of the above code is available on https://github.com/thecodinganalyst/graphql/blob/main/src/main/java/com/hevlar/intro/graphql/controller/ProductController.java.