2023.08.25.금.TIL

heeh·2023년 8월 28일

TIL

목록 보기

72/82

2023.08.25.금.TIL

할 것
- 15시 스터디 (기술 문제 1개 + CS 문제 2개)
  - CS 문제
  - 기술 문제
- 스터디 이후 회의
  - 테스트 코드
  - 팔로우
- Vue JS

테스트 코드

참고
- https://tech.inflab.com/20230404-test-code/
- https://velog.io/@pih6585/테스트-코드-작성하기
@Autowired와 @Mock은 스프링 프레임워크와 Mockito 라이브러리에서 사용되는 애노테이션으로, 각각 스프링의 의존성 주입과 목 객체(Mock Object)를 다루는 데 사용됩니다.

@Autowired

@Autowired 애노테이션은 스프링 프레임워크에서 사용되며, 의존성 주입(Dependency Injection)을 수행하는 데 사용됩니다. 클래스의 필드, 생성자, 메서드에 붙여서 해당 컴포넌트나 빈을 주입할 수 있게 해줍니다. 스프링은 이 애노테이션을 사용하여 자동으로 필요한 빈(Bean)을 찾아서 주입합니다.

@Mock

@Mock 애노테이션은 Mockito 라이브러리에서 사용되며, 목 객체(Mock Object)를 생성하는 데 사용됩니다. 목 객체는 실제 객체를 흉내내면서 특정 동작을 시뮬레이션하거나, 객체 간의 상호작용을 검증하는 데 사용됩니다. 테스트할 때 실제 객체 대신 목 객체를 사용하여 행위나 상태를 확인하고 테스트하는 것이 가능해집니다.

@InjectMocks

@InjectMocks는 Mockito 프레임워크에서 사용되는 애노테이션으로, 테스트 대상 객체(클래스)에 목(Mock) 객체를 주입해주는 역할을 합니다. 주로 테스트 대상 객체에 목 객체를 주입하여 테스트 환경을 구성할 때 사용됩니다.

예를 들어, 아래와 같은 클래스가 있다고 가정해봅시다:

javaCopy code
public class CommentController {
    private CommentService commentService;

    // 생성자와 메서드 등
}

위의 CommentController 클래스에서 CommentService 객체에 대한 의존성이 있습니다. 이 클래스를 테스트할 때 실제 CommentService 객체 대신 목 객체를 주입하고 싶다면 @InjectMocks를 사용할 수 있습니다.

javaCopy code
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;

public class CommentControllerTest {

    @InjectMocks
    private CommentController commentController;

    @Mock
    private CommentService commentService;

    // 테스트 메서드들
}

위의 예시에서 @InjectMocks는 CommentController 객체에 @Mock로 선언한 CommentService 객체를 주입해줍니다. 이렇게 하면 테스트할 때 commentController 내부에서 commentService 객체를 목 객체로 사용하게 됩니다.

주의: @InjectMocks는 필드 주입을 사용하여 객체를 주입하므로, 주입받을 필드는 private이어야 합니다. 생성자 주입과 같은 다른 주입 방법과는 약간 다른 접근 방식이므로, 코드 품질과 유지보수성을 고려하여 사용하시면 됩니다.

테스트 코드에 사용되는 애노테이션

@Test: JUnit 프레임워크에서 테스트 메서드임을 나타내는 애노테이션입니다. 테스트 메서드로 인식되어 실행됩니다.
@Before / @BeforeEach: 각각 JUnit 4와 JUnit 5에서 사용되는 애노테이션으로, 각 테스트 메서드 실행 전에 실행할 초기화 작업을 지정합니다.
@After / @AfterEach: 각각 JUnit 4와 JUnit 5에서 사용되는 애노테이션으로, 각 테스트 메서드 실행 후에 실행할 마무리 작업을 지정합니다.
@BeforeClass / @BeforeAll: 각각 JUnit 4와 JUnit 5에서 사용되는 애노테이션으로, 해당 클래스 내의 테스트 메서드들이 실행되기 전에 한 번만 실행할 초기화 작업을 지정합니다.
@AfterClass / @AfterAll: 각각 JUnit 4와 JUnit 5에서 사용되는 애노테이션으로, 해당 클래스 내의 테스트 메서드들이 모두 실행된 후에 한 번만 실행할 마무리 작업을 지정합니다.
@DisplayName: JUnit 5에서 사용되는 애노테이션으로, 테스트 메서드의 이름을 가독성 좋게 변경할 수 있습니다.
@Disabled: JUnit 4와 JUnit 5에서 사용되는 애노테이션으로, 특정 테스트 메서드를 비활성화시킬 때 사용합니다.
@RunWith: JUnit 4에서 사용되는 애노테이션으로, 사용자 지정 테스트 실행기(runner)를 설정할 때 사용합니다. JUnit 5에서는 @ExtendWith를 사용합니다.
@ExtendWith: JUnit 5에서 사용되는 애노테이션으로, 테스트 확장(extension)을 설정할 때 사용합니다. 예를 들어, Mockito 확장이나 Spring 확장을 사용할 수 있습니다.
@Mock: Mockito에서 사용되는 애노테이션으로, 목(Mock) 객체를 생성할 때 사용합니다.
@InjectMocks: Mockito에서 사용되는 애노테이션으로, 테스트 대상 객체에 목 객체를 주입할 때 사용합니다.
@SpringBootTest: Spring Boot에서 사용되는 애노테이션으로, 통합 테스트를 위해 Spring Boot 애플리케이션 컨텍스트를 로드합니다.
@WebMvcTest: Spring Boot에서 사용되는 애노테이션으로, 웹 계층을 테스트할 때 필요한 빈들만 로드합니다.
@DataJpaTest: Spring Boot에서 사용되는 애노테이션으로, JPA 레포지토리를 테스트할 때 필요한 빈들만 로드합니다.
@MockBean: Spring Boot에서 사용되는 애노테이션으로, 목(Mock) 빈을 생성하고 애플리케이션 컨텍스트에 주입합니다.

Mock "모의 객체(Mock Object)" 또는 간단히 "목(Mock)"은 소프트웨어 테스트에서 실제 객체의 동작을 흉내 내거나 모방하여 사용하는 객체입니다. 테스트 시에 실제 의존성을 가진 객체를 대신하여 사용할 수 있습니다.

기술 문제 9

💡 TCP/UDP에 대해서 설명해주세요.

참고

TCP/UDP

TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)는 둘 다 인터넷 프로토콜 스위트에서 사용되는 전송 계층 프로토콜로, 데이터 통신을 제어하고 관리하는 역할을 합니다. 그러나 이 둘은 서로 다른 특징과 용도를 가지고 있습니다.

TCP (Transmission Control Protocol):

연결 지향적 프로토콜: 통신 시작 전에 연결을 설정하고, 통신 후에는 연결을 정리합니다. 이로써 신뢰성 있는 데이터 전송을 보장합니다.
데이터 전달 보증: 데이터의 순서와 완전성을 보장하며, 데이터가 손실되면 재전송을 통해 보완합니다.
흐름 제어와 혼잡 제어: 데이터의 흐름을 조절하여 송신측과 수신측 간의 데이터 전송 속도 차이를 조절하며, 네트워크 혼잡을 피하기 위한 기능을 가지고 있습니다.
높은 신뢰성: 오류 발생 시 재전송과 데이터 순서 보장으로 안정적인 통신을 제공합니다.
대표적으로 웹 브라우징, 이메일, 파일 전송 등에 사용됩니다.

UDP (User Datagram Protocol):

비연결성 프로토콜: 연결 설정이나 정리 과정이 없이 데이터 그램을 보냅니다. 따라서 신속한 데이터 전송이 가능합니다.
데이터 전달 보증 없음: 데이터의 순서와 완전성을 보장하지 않습니다. 따라서 데이터가 손실되더라도 재전송을 하지 않습니다.
흐름 제어와 혼잡 제어 없음: 데이터를 그냥 보내기만 하므로 흐름 제어나 혼잡 제어 메커니즘이 없습니다.
낮은 오버헤드: 연결 설정과 순서 보장의 오버헤드가 없어 빠른 데이터 전송이 가능합니다.
대표적으로 실시간 스트리밍, 온라인 게임, DNS(Domain Name System) 등에 사용됩니다.

요약하면, TCP는 신뢰성과 데이터 순서 보장을 중요시하는 상황에서 사용되며, UDP는 빠른 데이터 전송이 중요한 상황에서 사용됩니다.

TCP/UDP 예제

TCP 예제:
웹 브라우징, 이메일 전송, 파일 전송 등에서 사용됩니다. 데이터 신뢰성이 중요한 상황에 적합합니다.

예를 들어, 웹 브라우징에서 사용되는 HTTP 프로토콜은 TCP 위에서 동작합니다. 클라이언트(브라우저)가 서버에 웹 페이지를 요청하면 서버는 해당 페이지 데이터를 신뢰성 있게 전송하여 올바른 내용이 정확한 순서로 표시되도록 합니다.

UDP 예제:
실시간 온라인 게임, 음성 및 비디오 스트리밍, DNS(Domain Name System) 등에서 사용됩니다. 데이터 전송 속도가 중요한 상황에 적합합니다.

예를 들어, 온라인 게임에서는 빠른 데이터 전달이 필요하므로 UDP를 사용하여 게임 서버와 클라이언트 간의 실시간 데이터 교환을 수행합니다. 게임에서는 속도가 중요하기 때문에 일부 데이터의 손실이나 순서 변경이 큰 문제가 되지 않을 수 있습니다.

이처럼 TCP와 UDP는 각각의 특성에 따라 다양한 분야에서 활용되며, 데이터의 신뢰성과 전송 속도에 따라 선택하여 사용합니다.

답

TCP(Transmission Control Protocol)는 신뢰성 있는 연결 지향적 프로토콜로, 데이터를 순서대로 전송하고 손실된 데이터를 재전송하여 안정적인 통신을 제공하며 데이터의 흐름과 혼잡을 관리하여 안정적인 데이터 교환을 할 수 있습니다. UDP(User Datagram Protocol)는 연결 없이 빠르게 데이터를 전송하는 비신뢰성 프로토콜로, 순서와 완전성을 보장하지 않고 신속한 데이터 전달을 중요시하는 통신에 사용됩니다.
나만의 피드백
- TCP/UDP 예제를 미리 좀 더 알아보면 좋았을 것 같다!

CS 문제 3

💡 프로세스 생명주기와 프로세스 메모리

질문1 : 프로세스 상태 (Status)의 순서는?
- 답변 1
  - 신규(New) - 준비(Ready) - 수행(Running) - 대기(Watinig) - 종료(Terminated)
  - 신규(New)
    - 프로세스가 이제 막 메인메모리에 올라온 상태입니다.
    - 아직, 실행하는 것은 불가능합니다.
    - 수용 동작을 거쳐야 준비단계로 넘어갑니다.
  - 준비(Ready)
    - 변수 초기화 등 기초 준비작업을 모두 끝나고 실행을 할 수 있는 상태입니다.
    - 스케쥴러를 통해 발송(dispatch)되어야 수행상태가 됩니다.
    - 아래 케이스를 통해 준비상태가 됩니다.
      - 신규 프로세스가 수용됨
      - 대기 프로세스의 입출력/이벤트가 완료됨
      - 수행 프로세스가 중단됨
  - 수행(Running)
    - CPU가 실제로 프로세스를 수행하고 있는 상태입니다.
    - 선점 스케쥴링에 의해 중단되면 준비상태로
    - 입출력/이벤트가 필요하면 대기상태로
    - 수행이 완료되면 종료상태가 됩니다.
    - 아래 케이스를 통해 수행상태가 됩니다.
      - 준비 프로세스가 스케쥴러를 통해 발송됨
  - 대기(Watinig)
    - 프로세스 도중에 I/O 작업이 필요하여 I/O 작업을 수행하는 상태입니다.
    - 이 때 CPU는 I/O를 기다리며, 다른 프로세스를 수행합니다.
    - 대기 상태가 끝나면 프로세스는 다시 준비 상태가 되고, 잠시 후 다시 수행 상태가 됩니다.
  - 종료(Terminated)
    - 최종적으로 프로세스가 종료된 상태입니다.
    - 사용하던 메모리 영역이 해제됩니다.
질문 2 : 대기 큐 (Waiting Queue)는 프로세스 상태 (Status)의 언제 발생?
- 답변 2
  - 대기 큐(대기열, Waiting Queue)는 프로세스 스케줄링에서 "준비 상태(Ready State)"에서 "수행 상태(Running State)"로 전환될 때 발생합니다. 프로세스 스케줄러는 준비 상태의 프로세스 중에서 CPU를 할당할 프로세스를 선택하여 수행 상태로 전환하게 됩니다. 이 과정에서 준비 상태에서 실행 상태로 이동할 프로세스가 없거나, 해당 CPU가 다른 프로세스에 의해 점유 되어 있을 때 대기 큐에 있는 프로세스들이 대기하게 됩니다. 대기 큐에 있는 프로세스들은 CPU가 해제되고, 스케줄러가 선택하여 실행 상태로 전환해 줄 때까지 기다립니다. 이를 통해 다중 프로세스 환경에서 공정한 CPU 할당 및 프로세스 우선순위에 따른 작업 스케줄링이 가능해집니다.
질문 3 : 대기 큐 (Waiting Queue)에 대해서 설명?
- 답변 3
  - 대기 큐는 프로세스 스케줄링에서 사용되는 중요한 개념으로, CPU 실행을 기다리는 프로세스들이 순서대로 대기하는 공간입니다. 준비 상태에서 수행 상태로 넘어갈 때 CPU가 사용 가능한지 여부에 따라 대기 큐에 프로세스를 대기시킵니다. 이 큐는 스케줄링 알고리즘에 따라 프로세스를 선택하여 수행 상태로 이동시킵니다. 대기 큐는 시스템의 효율적인 리소스 활용과 프로세스 우선순위에 따른 작업 조정을 가능케 하며, 다중 프로세스 환경에서 프로세스의 공정한 실행을 보장합니다.
  - Job Queue
    - HDD의 프로그램들이 잠시 기다리는 곳
  - Ready Queue
    - 이미 메모리에 올라온 프로세스들이 실행을 위해 대기하는 곳
  - Device Queue
    - 프린터는 프린터큐, 마우스는 마우스큐, 키보드는 키보드큐와 같이 각각 I/O 장치들은 각자의 대기 큐를 가지고 있는데, 이러한 I/O 장치들의 큐들을 통틀어서 부르는 것
    - I/O 장치?
      - I/O(입출력) 장치, 컴퓨터 시스템에서 데이터를 입력받거나 출력하는 데 사용되는 장치들을 의미
질문 4 : 스케줄러? 스케줄링?
- 답변 4
  - 스케줄러 (Scheduler):
    스케줄러는 주로 운영 체제에서 사용되는 개념으로, 프로세스나 작업의 실행 순서와 우선순위를 관리하는 역할을 합니다. CPU 스케줄러, 디스크 스케줄러, 네트워크 스케줄러 등 다양한 종류의 스케줄러가 있습니다. CPU 스케줄러는 준비 상태에 있는 프로세스 중 어떤 것을 실행시킬지 결정하며, 디스크 스케줄러는 디스크에 입출력 요청이 있을 때 어떤 요청을 먼저 처리할지 결정합니다.
  - 스케줄링 (Scheduling):
    스케줄링은 더 일반적인 개념으로, 어떤 작업을 어느 순서로 처리할 것인지 결정하는 과정을 의미합니다. 이는 운영 체제뿐만 아니라 다양한 분야에서 사용될 수 있습니다. 예를 들어, 작업 관리, 자원 할당, 프로젝트 일정 관리 등에서 스케줄링이 사용됩니다.
    
    요약하면, 스케줄러는 특정 작업을 처리하는 역할을 하며 주로 운영 체제에서 사용되며, 스케줄링은 작업들을 어떤 순서로 처리할지 결정하는 일반적인 개념으로 다양한 분야에서 사용됩니다.