feat: add favorite tech stack

Author: sivaprasadreddy

docs/recommendations.md

@@ -1,6 +1,18 @@
 # Recommendations
 
-## 1. Unit vs Integration Tests
+## What is your recommended tech stack for Java backend development?
+- **Language:** Java / Kotlin
+- **Frameworks:** Spring Boot, Quarkus
+- **Design & Architecture:** Modular Monolith, Package-by-Feature
+- **Database:** PostgreSQL, Flyway Migrations
+- **Testing:** Integration Tests with Testcontainers, Unit Tests with Mockito, API Stubbing with WireMock
+- **Architecture Tests:** Spring Modulith Tests, ArchUnit Tests with Taikai
+- **Library Upgrades:** Renovate, Dependabot, OpenRewrite
+- **IDE:** IntelliJ IDEA
+- **Build Tool:** Maven
+- **Code Formatting:** Spotless Plugin with Palantir Java Format
+
+## Unit vs Integration Tests
 I used to strictly follow the [Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html) approach, but over time, I've realized that it's not always the most effective strategy. Many of the applications I've worked on have relatively simple business logic but rely heavily on integrations with external systems such as SQL databases, messaging systems, and third-party REST APIs. For such applications, unit tests often provide limited value. Instead, I recommend focusing on integration tests that validate how the application behaves when interacting with real external systems.
 
 That said, it's not about choosing only unit tests or only integration tests. The most effective testing strategy involves a balanced mix of different types of tests to ensure comprehensive coverage and reliable behavior.
@@ -10,12 +22,12 @@ That said, it's not about choosing only unit tests or only integration tests. Th
 3. **Slice Tests:** While integration tests are valuable, it's not always necessary to spin up all dependencies for certain scenarios. For example, when testing invalid REST API payloads, you don't need a database or message broker. In such cases, slice tests are ideal — they load only a subset of components while mocking the rest. In Spring Boot, you can use annotations like `@WebMvcTest`, `@DataJpaTest`, and others to achieve this.
 
 
-## 2. Testcontainers tests are taking too much time. What should I do?
+## Testcontainers tests are taking too much time. What should I do?
 1. Use [Testcontainers Singleton approach](https://www.sivalabs.in/blog/run-spring-boot-testcontainers-tests-at-jet-speed/) to use the same containers for all tests.
 2. Use [Testcontainers reuse](https://java.testcontainers.org/features/reuse/) feature to keep the containers running in the background instead of stopping and restarting.
 3. If you are using Testcontainers with PostgreSQL, consider using [dbsandboxer](https://github.com/misirio/dbsandboxer) to speed up test execution by using PostgreSQL's template database feature.
 
-## 3. Mockito vs In-Memory Implementation for Mocking
+## Mockito vs In-Memory Implementation for Mocking
 When writing unit tests for a service layer class(`CustomerService`), a common challenge is managing its dependencies, such as the `CustomerRepository`. We need a way to isolate the service logic from the actual data access implementation to ensure the test only validates the service's behavior. Two primary techniques for achieving this isolation are using a mocking framework like Mockito or creating an In-Memory implementation of the dependency.
 
 Let's assume the following simplified interfaces and class structures:
@@ -246,14 +258,14 @@ For example, a test verifying a feature expects a search query to return 23 reco
 
 So, I recommend using Mockito so that you control the exact conditions of the test without the maintenance overhead and brittleness associated with managing a secondary, in-memory dependency implementation.
 
-## 4. Should I aim for 100% Test Coverage?
+## Should I aim for 100% Test Coverage?
 Striving for 100% test coverage often leads to a blind ritual rather than a genuine pursuit of quality. While the metric was intended to encourage thorough testing, obsessively chasing the final few percentage points frequently results in writing trivial, brittle tests that simply confirm getter/setter calls or other low-value code, without actually verifying meaningful system behavior. 
 
 The reality is that high test coverage doesn't necessarily mean high-quality code; a project can have 100% coverage yet still fail to test critical business logic or edge cases. 
 
 Instead of a rigid target, a more pragmatic approach is to aim for a solid foundation, such as 80% code coverage, prioritizing a good test suite focused on verifying system behavior, complex logic, and integration points, which provides the most value for maintaining a robust application.
 
-## 5. How to enforce a common coding style in a team?
+## How to enforce a common coding style in a team?
 Code formatting and linting are frequently discussed — and sometimes hotly debated — topics within development teams. In reality, these discussions often consume more time than they should. Once a team agrees on a standard formatting approach, it typically becomes second nature within a week, and few developers think about it again.
 
 To maintain consistency and avoid unnecessary debates, it’s best to adopt a well-established tool and automate formatting as part of your build or CI process. Some popular options include: