자바스크립트 안에서 <div>, <button> 같은 HTML 유사 마크업 문법을 쓸 수 있게 해주는 확장 문법. React가 만든 개념. UI 구조를 코드로 표현할 때 사용.
TS (.ts)
타입스크립트. JS + 정적 타입 시스템. 컴파일 시 타입 오류 검출
TSX (.tsx)
TS + JSX 문법 허용. React에서 <div>..</div> 같은 마크업을 TS 코드 안에 쓸 때 사용. TSX는 TS의 특수 확장자로 컴포넌트 파일에서만 필요.
// jsx
// 브라우저가 직접 이해하는 문법이 아님
// Babel 같은 컴파일러가 순수 JS로 변환
const element = <h1>안녕하세요</h1>;
// 내부적으로 다음과 같은 형태로 변환
React.createElement('h1', null, '안녕하세요')
순수 로직 파일(유틸 함수 등)은 .ts, UI 렌더링이 들어간 파일은 .tsx
Selenium이란
웹 브라우저를 코드로 제어해 UI 자동화 테스트를 수행하는 오픈소스 프레임워크
실제 브라우저(Chrome, Firefox 등)를 구동해 클릭, 입력, 페이지 이동 등을 시뮬레이션
WebDriver API를 통해 여러 언어(Java, Python, JS 등)에서 제어 가능
E2E(End-to-End) 테스트, 크롤링/스크래핑에도 활용
단점: 실행 속도 느림, 유지보수 비용 높음 (요소 선택자 변경에 취약) -> 최근엔 Playwright, Cypress가 대안으로 많이 쓰임
Playwright
Microsoft가 개발한 오픈소스 브라우저 자동화 라이브러리
Selenium과 목적은 같지만(브라우저 제어), 설계 철학과 아키텍처가 훨씬 최신
E2E 테스트 프레임워크
Selenium과 달리 auto-wait가 내장되어 대기 로직을 직접 짤 필요가 없다
Locator 기반 설계로 요소를 동작 시점에 평가해 타이밍 이슈에 강하다
시맨틱 셀렉터를 지원하여 Selenium의 셀렉터 취약성 문제를 완화
WebDriver API
브라우저를 외부에서 프로그래밍적으로 제어할 수 있게 해주는 표준 인터페이스(프로토콜)
E2E 테스트
End-to-End 테스트
사용자가 실제로 경험하는 흐름 전체를 처음부터 끝까지 검증하는 테스트
전체 시나리오를 한 번에 검 예: 회원가입 -> 로그인 -> 상품 장바구니 담기 -> 결제
아무도 안 궁금했던 근황: 보조강사 알바, 8/7 정보처리기사 필기 시험, 8/9 독학사 컴공 3단계 시험, 포트폴리오 만들어서 정규직으로 써달라고 메일 보내기
(바빴다는 뜻)
아무튼 ft_read를 만들어볼거예요~~
ft_read입니다
ft_read는 ft_write와 거의 대칭이지만, 함정이 하나 다릅니다.
구분
fd
buf
count
syscall 번호
ft_write
rdi
rsi
rdx
1
ft_read
rdi
rsi
rdx
0
syscall 번호와 에러 처리(push rax → call __errno_location wrt ..plt → pop qword [rax] → mov rax, -1) 구조는 ft_write에서 만든 걸 그대로 재사용할 수 있습니다.
다른 점 하나: write는 buf를 커널이 “읽기만” 하지만, read는 커널이 buf에 “쓰기”를 합니다. 이게 코드 자체에는 영향 없지만(어차피 syscall이 알아서 처리), 테스트 설계에는 영향을 줍니다 — NULL buf를 넘겼을 때 write는 EFAULT가 나는 지점이 “읽으려는 시도”였다면, read는 “쓰려는 시도”에서 EFAULT가 납니다. 결과적으로 에러 코드는 똑같이 EFAULT(14)이지만, count=0일 때는 write와 마찬가지로 커널이 buf 검사를 생략하고 0을 반환한다는 점도 동일합니다.
직접 NASM 코드를 작성해보시겠습니까? ft_write 코드를 골격으로 삼아 syscall 번호와 함수 이름만 바꾸는 방식으로 시작하시면 됩니다.
시스콜 넘버부터 찾아봤어요: sys_read는 0입니다.
mov rax, 0
syscall
아니 세상에 클로드가 번호 친절하게 알려줬는데 코앞에 두고 못 봤네;;; 이거 뭐지요??
근데 일단?? read 함수가 어떻게 동작할까?요??
write: fd(rdi)에 buf(rsi)의 내용을 count(rdx)만큼 쓸 것이다, syscall(rax) 1
read: fd(rdi)을 buf(rsi)에 count(rdx)만큼 읽을 것이다, syscall(rax) 0
이거잖아
그러니까 시스콜이 알아서 처리한 다음에, rax를 반환하는거지
rax >= 0, 쓰기 성공한 바이트 rax < 0, -errno
그러면 그냥 write 재사용하면 되는거잖아요…. 날 속였구나(아님)
그러면 ft_read를 구현하라는 게 무슨 의미가 있지? 시스콜 부를 때 rax 0 세팅이랑 테스트 코드만 다르잖아. 테스트코드 짜보라는 건가?