일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 호키스
- Svelte
- 자스민
- Hitit
- 힛잇
- 호키도키
- 개발
- react
- 리액트 예제
- javascript
- data structure
- 개발자
- 스위프트
- HTML
- hokidoki
- 자바스크립트 자료구조
- IOS
- 이종호
- 계명대 이종호
- 자바스크립트
- SWIFT
- TDD
- 비동기
- 리액트
- 계명대
- queue
- 스벨트
- jest
- 자료구조
- hokeys
- Today
- Total
목록힛잇 (22)
Dog foot print
Mock 함수는 테스트에서 사용 할 수 없는 함수(window.replace)와 함수에 어떤 파라메터가 전달되었는지, 인스턴스가 new 키워드로 생성되었을 때 생성자 함수를 캡쳐링 하는 것을 가능하게 도와준다. Mock 함수를 사용하는 방법은 두개가 존재한다. 이 두 방법은 test code에서 직접 Mock 함수를 생성하거나, 의존성 모듈에 직접 mock함수를 작성하는 방법이다. Using a mock function 다음과 같이 forEach 함수를 통해서 배열을 순회하며, 전달 된 callback으로 배열 내부에 아이템을 전달한다고 생각해보자. function forEach(items, callback) { for (let index = 0; index < items.length; index++) ..
Note : 제스트는 matcher를 사용하여, 사용자가 다양한 방식으로 값을 테스트 하게 도와줍니다. 이 문서는 주로 사용되는 matcher에 대해서 소개 하며, 모든 Mathcer에 대한 list는 다음의 링크를 참조하세요. 일반적인 Matcher들 다음 예제는 아주 간단한 방법으로 값이 예상하는 값과 일치하는지 확인 하는 방법입니다. test('two plus two is four',()=>{ expect(2 + 2).toBe(4); }) 이 코드에서, expect(2+2) 함수 호출은 ”expectation” 객체를 반환합니다. 일반적으로 이러한 expectation 객체에서 call matcher를 제외하고는 많은 작업을 수행하지 않습니다. 이 코드에서는.toBe(4) 가 Matcher 입니다...
서론 Jest 시작하기 시리즈 문서들은 TEST 도구인 JEST의 공식 홈페이지 문서를 번역하고 설명을 덧 붙인 문서입니다. 설치 * Yarn 을 이용한 설치 * $ Yarn add —dev jest * Npm 을 이용한 설치 * $ npm install —save-dev jest Note : 이 문서는 yarn command를 사용하지만, npm 또한 동일하게 동작합니다. JEST 실행하기 ./sum.js function sum(a,b){ return a + b; } ./sum.test.js const sum = require("./sum"); test("adds 1 + 2 to equal 3",()=>{ expect(sum(1,2)).toBe(3); }) ./package.json { ... "scr..
서론 지난 포스팅에 이어 마지막 DIP 에 대해서 포스팅 하겠습니다. DIP :(Dependency Inversion Principle) 의존관계 역전 원칙 의존성 역전 원칙에서 말하는 "유연성이 극대화된 시스템"이란 소스코드가 추상에 의존하며 구체에는 의존하지 않는 시스템을 의미한다. 추상 인터페이스에 변경이 생기면 이를 구체화한 구현체들도 따라서 수정해야 한다. 반대로 구체적인 구현체에 변경이 생기더라도 그 구현체가 구현하는 인터페이스는 항상 변경될 필요가 없다. 따라서 인터페이스는 구현체보다 변동성이 낮다. 즉 안정된 소프트웨어 아키텍처란 변동성이 큰 구현체에 의존하는 일은 지양하고, 안정된 추상 인터페이스를 선호하는 아키텍처라는 뜻이다. 이 원칙을 구체적인 코딩 실천법으로 요약 하면 다음과 같다...
서론 지난 포스팅에 이어 오늘은 [i]에 대해서 포스팅 하도록 하겠습니다. ISP (Interface Segregation Principal) : 인터페이스 분리 원칙 인터페이스 분리 원칙은 어떤 인터페이스로부터 상속받아 클래스를 정의 할 때, 사용하지 않는 메서드까지 상속 받지 말고 새로운 인터페이스를 생성하여 기존 상속하려던 인터페이스를 새롭게 확장하여 상속 받아야 한다는 분리원칙이다. 다음의 클래스다이어그램을 보도록 하자 . 위의 클래스 다이어그램에서 파리,벌,사슴벌레 클래스는 곤충 인터페이스를 상속받는다. 이 경우 파리 클래스에서는 독을 뿜다. 라는 메서드가 필요없으며, 벌 클래스와 사슴벌레 클래스에서는 각각 뿔을 움직인다, 독을 뿜다라는 메서드가 필요없음에도 곤충인터페이스를 상속 받았기 때문에 ..
서론 지난 포스팅에 이어 SOLID 원칙 중 [L]에 대해서 포스팅을 이어나가보도록 하겠다. LSP(Liskov substitution Principle) : 리스코프 치환 법칙 리스코프는 하위타입에 대해서 다음과 같이 정의하였다. "S타입의 객체 o1 각각에 대응하는 T타입 객체 o2가 있고, T타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면,S는 T의 하위 타입이다. " 리스코프의 말이 어렵게 느껴지는 것이 당연하다. 이를 조금 더 쉽게 풀어 설명하면, 다음과 같다. "부모 A로부터 상속받은 자식 B가 존재할 때 부모 A는 자식 B로 타입을 치환하여도 프로그램에서 행위는 변하지 않는다. " 어찌 보면 당연한 소리이다. 부모 A로부터 만들어진 ..