Field injection and why to avoid it in Spring Boot - Step-by-Step Execution

Concept Flow - Field injection and why to avoid it

Start: Spring creates bean

↓

Inject dependencies via fields

↓

Bean ready to use

↓

Problems arise: hard to test, hidden dependencies

↓

Better: use constructor injection

↓

Clear dependencies, easier testing, immutable fields

Spring creates a bean and injects dependencies directly into fields, which works but causes hidden problems. Using constructor injection instead makes dependencies clear and testing easier.

Execution Sample

Spring Boot

public class MyService {
  @Autowired
  private UserRepository userRepository;

  public void doWork() {
    userRepository.save(new User());
  }
}

This code shows field injection where Spring sets the userRepository field directly before the bean is used.

Execution Table

Step	Action	Field userRepository	Result
1	Spring creates MyService instance	null	Instance created, userRepository not set yet
2	Spring injects UserRepository into userRepository field	UserRepository instance	Dependency injected silently
3	doWork() called	UserRepository instance	userRepository.save() called successfully
4	Testing scenario	null or mock	Hard to inject mock, field is private and hidden
5	Conclusion	UserRepository instance	Field injection hides dependencies, hard to test

💡 Field injection completes but causes hidden dependencies and testing difficulties

Variable Tracker

Variable	Start	After Injection	After Method Call	Final
userRepository	null	UserRepository instance	UserRepository instance	UserRepository instance

Key Moments - 3 Insights

Why is it hard to test a class using field injection?

Because the dependency is injected directly into a private field (see execution_table step 4), it is not easy to replace it with a mock or stub during tests.

What does Spring do when it injects dependencies via fields?

Spring sets the private field directly after creating the instance (execution_table step 2), which happens silently and hides the dependency from the constructor.

Why is constructor injection preferred over field injection?

Constructor injection makes dependencies explicit and immutable, improving clarity and testability (refer to concept_flow and key_moments).

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of userRepository after Spring injects it?

A UserRepository instance

B Mock object

C null

D Undefined

💡 Hint

Check execution_table row 2 under 'Field userRepository'

At which step does the difficulty in testing appear according to the execution_table?

A Step 1

B Step 2

C Step 4

D Step 3

💡 Hint

Look for the step mentioning testing challenges in execution_table

If we switch to constructor injection, how would the variable_tracker change?

A userRepository would be null throughout

B userRepository would be set at object creation

C userRepository would be set after method call

D userRepository would be set to null after injection

💡 Hint

Constructor injection sets dependencies when the object is created, not later (see concept_flow)

Concept Snapshot

Field injection uses @Autowired on private fields.
Spring sets these fields after creating the object.
This hides dependencies and makes testing hard.
Constructor injection passes dependencies via constructor.
It makes dependencies clear and easier to test.
Avoid field injection for better code quality.

Full Transcript

Field injection in Spring Boot means putting @Autowired on private fields so Spring sets them after creating the object. This works but hides what the class needs, making it hard to test because you cannot easily replace those fields with mocks. The execution table shows Spring creating the object, then injecting the dependency silently into the field. Testing is difficult because the field is private and not set via constructor. Constructor injection is better because it makes dependencies clear and immutable, improving readability and testability. Avoid field injection to write cleaner, easier-to-test code.

Practice

1. What is a main reason to avoid using @Autowired directly on fields in Spring Boot?

easy

A. It disables Spring Boot auto-configuration

B. It causes syntax errors in the code

C. It requires manual object creation

D. It hides dependencies and makes testing harder

Solution

1. Step 1: Understand field injection behavior

   Field injection uses @Autowired on fields, which hides the dependencies inside the class without showing them in the constructor.

2. Step 2: Analyze impact on testing

   Because dependencies are hidden, it becomes harder to create test instances with mocks or stubs, reducing testability.

3. Final Answer:

   It hides dependencies and makes testing harder -> Option D

4. Quick Check:

   Hidden dependencies = avoid field injection [OK]

Hint: Hidden dependencies make testing tough, avoid field injection [OK]

Common Mistakes:

• Thinking field injection causes syntax errors
• Believing field injection disables auto-configuration
• Assuming field injection requires manual object creation

2. Which of the following is the correct way to inject a dependency using constructor injection in Spring Boot?

easy

A. @Autowired private Service service;

B. Service service = new Service();

C. public MyClass(Service service) { this.service = service; }

D. @Autowired public void setService(Service service) { this.service = service; }

Solution

1. Step 1: Identify constructor injection syntax

   Constructor injection requires a constructor that accepts the dependency as a parameter and assigns it to a field.

2. Step 2: Match the correct code

   public MyClass(Service service) { this.service = service; } shows a constructor receiving Service and assigning it, which is the correct pattern.

3. Final Answer:

   public MyClass(Service service) { this.service = service; } -> Option C

4. Quick Check:

   Constructor injection = constructor with parameters [OK]

Hint: Constructor injection uses constructor parameters, not field annotations [OK]

Common Mistakes:

• Confusing field injection with constructor injection
• Using manual object creation instead of injection
• Using setter injection when constructor injection is asked

3. Given this Spring Boot class using field injection:

public class MyService {
  @Autowired
  private Repository repo;

  public String getData() {
    return repo.fetch();
  }
}

What is a likely problem when writing unit tests for MyService?

medium

A. The getData() method will not compile

B. You cannot replace repo with a mock easily

C. The repo field will always be null at runtime

D. Spring Boot will throw a runtime exception on startup

Solution

1. Step 1: Understand field injection impact on testing

   Field injection hides the dependency inside the private field, making it hard to inject a mock instance during unit tests.

2. Step 2: Analyze testability of MyService

   Since repo is private and injected by Spring, test code cannot easily replace it with a mock, limiting test control.

3. Final Answer:

   You cannot replace repo with a mock easily -> Option B

4. Quick Check:

   Field injection blocks mock replacement [OK]

Hint: Field injection hides fields, blocking mock injection in tests [OK]

Common Mistakes:

• Assuming compilation errors occur
• Thinking Spring throws exceptions on field injection
• Believing the field is always null at runtime

4. Identify the problem in this Spring Boot class using field injection:

public class UserService {
  @Autowired
  private UserRepository userRepository;

  public UserService() {}

  public User findUser(Long id) {
    return userRepository.findById(id).orElse(null);
  }
}

medium

A. Field injection hides dependencies making testing harder

B. Constructor is missing the @Autowired annotation

C. The userRepository field should be static

D. The findUser method should be static

Solution

1. Step 1: Review injection style

   The class uses field injection with @Autowired on a private field, which hides dependencies.

2. Step 2: Understand testing impact

   Because dependencies are hidden, it is harder to inject mocks or stubs for unit testing, reducing testability.

3. Final Answer:

   Field injection hides dependencies making testing harder -> Option A

4. Quick Check:

   Field injection = hidden dependencies = testing difficulty [OK]

Hint: Field injection hides dependencies, causing test problems [OK]

Common Mistakes:

• Thinking constructor needs @Autowired always
• Believing fields must be static for injection
• Assuming methods must be static for injection

5. You have a Spring Boot service class that uses field injection:

public class OrderService {
  @Autowired
  private PaymentService paymentService;

  public boolean processOrder(Order order) {
    return paymentService.charge(order.getAmount());
  }
}

How would switching to constructor injection improve this class?

hard

A. It makes dependencies explicit and improves testability

B. It removes the need to annotate fields with @Autowired

C. It automatically creates new instances of dependencies

D. It allows Spring to inject dependencies without a constructor

Solution

1. Step 1: Understand constructor injection benefits

   Constructor injection requires dependencies to be passed in explicitly, making them visible and clear in the class design.

2. Step 2: Analyze testability improvements

   Explicit dependencies allow easy replacement with mocks or stubs during testing, improving testability and code clarity.

3. Final Answer:

   It makes dependencies explicit and improves testability -> Option A

4. Quick Check:

   Constructor injection = explicit dependencies + better tests [OK]

Hint: Constructor injection shows dependencies clearly, aiding tests [OK]

Common Mistakes:

• Thinking constructor injection removes @Autowired completely
• Believing constructor injection creates new instances automatically
• Assuming Spring injects without constructor or annotations