[feat] Rest Docs 적용

[linglong67]

💡 Motivation and Context

테스트 코드 성공 시, Rest Docs를 통해 API 문서화를 할 수 있습니다

🔨 Modified

Rest Docs를 적용했고, 샘플 코드를 작성했습니다

아래는 적용 방식을 설명합니다

1. ControllerTest

• 이후 Controller 테스트는 ControllerTest.java를 상속받아 사용
• @WebMvcTest 테스트할 컨트롤러를 추가
• 테스트 시 필요한 서비스 추가 (@MockBean)
  

2. 도메인별 ControllerTest

• ControllerTest.java를 상속
  
• ControllerTest (추상클래스)에서 MockMvc, 도메인 Service 등이 모두 주입되기 때문에 아래 내용 불필요
  (단, FixtureMonkey는 주입이 안되서 사용하는 테스트 파일에 별도로 추가 필요해보임)
  
• 실제 사용 예시는 CommonCodeControllerRestDocsTest.java 로 확인 가능

3. 도메인별 adoc 파일 관리

• 메서드별 테스트 성공 시, src/docs/asciidoc 하위에 도메인별 adoc 파일을 추가하여 관리
• index.adoc 에서 도메인별 adoc을 include 함 (결과적으로, 도메인/docs/index.html 에 접근하여 API 문서 확인)
• 실제 사용 예시는 sample-api.adoc 로 확인 가능

🌟 More

• 2, 3번 샘플에 대해 추가적으로 설명드리고 싶은 부분이 있어 오후에 회의를 했으면 좋겠습니다
• 삭제 예정 파일이나 내용에 대해 명시해두었습니다 (Rest Docs 방식이 자리 잡으면 추후에 삭제 예정입니다)

---

📋 커밋 전 체크리스트

• 추가/변경에 대한 단위 테스트를 완료하였습니다.
• 컨벤션에 맞게 작성하였습니다.

🤟🏻 PR로 완료된 이슈

closes #72

[cr-gpt]

Here are some findings and suggestions for the code patch:

1. Dependency Upgrade: Consider upgrading the dependencies to their latest versions, as newer versions often include bug fixes and improvements.

2. Configuration Block: Move the ext block inside the java block for better organization.

3. Output Directory: Add the output directory for Asciidoctor generated snippets (snippetsDir) as an input for the asciidoctor task to track changes properly.

4. Configuration Name: Change asciidoctorExt to a more descriptive name, like restdocsAsciidoctor, as it is used for Spring REST Docs.

5. Ensure Clean Slate: Delete the existing src/main/resources/static/docs directory before generating new documentation to avoid any stale files remaining.

6. Documentation Copy: Create a task named copyDocument that depends on the asciidoctor task. This task copies the generated AsciiDoc files from build/docs/asciidoc to src/main/resources/static/docs.

7. Jar Creation: Configure the bootJar task to depend on the copyDocument task so that the generated documentation is included in the final JAR file.

Overall, these changes improve the build process and ensure that the latest documentation is included in the application's distribution.

[cr-gpt]

The code patch you provided seems to be a .gitignore file. It specifies the files and directories that should be ignored by Git when tracking changes in a project. Here are some observations and suggestions based on the provided patch:

1. It's generally a good practice to include a top-level directory, such as the project root, before specifying individual files and directories to ignore. This ensures that the .gitignore rules apply correctly to the entire project.

2. The HELP.md file is mentioned at the beginning of the patch. If this file is meant to be ignored, it should be removed from version control. Otherwise, it will continue to be tracked.

3. The exclusion patterns using ! (e.g., !**/src/main/**/build/) are intended to override previous ignore patterns and include specific files or directories. Make sure these patterns align with your project structure and desired behavior.

4. It's recommended to exclude generated build artifacts like build/, bin/, and out/ directories to avoid including compiled files in version control. However, be cautious when applying such exclusions to ensure necessary build configuration files are not inadvertently ignored.

5. Integrated development environment (IDE)-specific directories and files like .gradle, .idea, and .vscode/ are excluded. This assumes that developers using different IDEs will generate their own specific configuration files without affecting the core project.

6. The */src/main/*/out/ and */src/test/*/out/ patterns suggest excluding specific output directories from source directories that may contain generated files. This can be helpful to avoid including intermediate build results.

7. The /src/main/resources/static/docs directory is included, implying that its contents should be tracked in version control. Ensure this matches the intended behavior; otherwise, if the documentation is dynamically generated or updated during builds, it may be better to exclude it.

Remember to periodically review and update your .gitignore file as the project evolves and new files or build artifacts are introduced. Additionally, consider collaborating with other developers on the project to fine-tune the ignore rules based on their respective development environments and tools.

[HyunJunSon]

LGTM

[cr-gpt]

The code patch you provided mainly consists of changes to the .gitignore file. It appears that the patch updates the list of files and directories that should be ignored by Git.

The added line !**/src/main/**/static/docs suggests that the rule for ignoring files in the static/docs directory has been reversed. Instead of ignoring it, the patch instructs Git to include these files in the repository. This change is likely intentional to ensure that the REST documentation (static/docs) is now being tracked by Git.

Regarding bug risks and improvement suggestions, it's challenging to provide a comprehensive review without more context or visibility into your project. However, here are a few general considerations:

1. Ensure the importance of each change: Review all modifications made by the patch to confirm they are necessary for your project. Superfluous changes can introduce unnecessary complexity and increase the risk of errors.

2. Validate the updated .gitignore rules: Check whether the new patterns added to the .gitignore file accurately match the files and directories you intend to ignore or include.

3. Assess the handling of sensitive or generated files: Pay attention to how sensitive files (e.g., configuration files containing passwords) and automatically generated files are managed. Make sure they are appropriately excluded and not inadvertently committed to the repository.

4. Consider using version control for documents cautiously: Including documentation files in the repository can lead to larger repository sizes and possible merge conflicts. Verify that this decision aligns with your project requirements and preferences.

Ultimately, a thorough code review considers the broader context, architecture, and goals of the project. It may be beneficial to involve other team members or utilize code review tools to help analyze the changes in detail and provide specific recommendations for improvement.

[HyunJunSon]

LGTM

[cr-gpt]

The provided code patch appears to be written in AsciiDoc format and aimed at generating an API documentation book. Here are some observations and suggestions:

1. It is missing the AsciiDoc header that defines document attributes, such as the title, author, and date. Make sure to add those attributes for a complete documentation.
2. The "include" statements at the bottom indicate the inclusion of other AsciiDoc files (overview.adoc and sample-api.adoc). Check if these file paths are correct and if the content they provide is relevant and up-to-date.
3. The line "// FIXME :: 위 라인 1줄은 추후 삭제 예정입니다" seems to be a comment indicating that it should be removed later. It's good to have a plan for clearing out such placeholders after taking the necessary actions. Make sure to remove it when appropriate.
4. Consider adding more sections to the table of contents (TOC) by adjusting the :toclevels attribute based on the desired depth of the TOC.

Since this is only a small portion of your code, a more comprehensive review might require examining the included AsciiDoc files and the overall structure of your API documentation.

[chan99k]

LGTM

[gunsight1]

회의 통해서 설명 잘 들었습니다 LGTM