TOAST UI

테스트 자동화와 테스트 전략의 중요성, 시각적 테스트를 자동화하는 것이 어려운 이유 등을 살펴보았다. 사실 시각적 테스트를 자동화하는 것이 불가능하지는 않지만, 현재 우리가 가진 도구로는 기대하는 만큼 효용을 얻기가 어렵다. 이 글은 "실용적인" 테스트 전략을 다루고 있으므로, 한발 물러서서 다른 접근 방식을 시도해 보도록 하겠다. 즉, 결과물을 시각적으로 검증하는 행위는 자동화하지 않고 "사람의 눈"에 맡기되, 검증을 위한 준비 작업을 최대한 자동화하는 것이다. 이러한 작업을 위한 가장 효과적인 도구가 바로 스토리북이다.

2018년은 FE개발랩에 좋은 일이 많은 한 해였다. 랩에서 내놓은 오픈소스 프로젝트들이 좋은 반응을 얻었고, 몇 가지 의미있는 성과를 얻었다. 아직 오픈소스 생태계에서 큰 역할을 하지 못하는 대한민국에서 좋은 오픈소스 프로젝트들이 많이 나왔으면 하는 바람으로 몇 년간 우리가 오픈소스를 운영하면서 얻은 나름의 결과를 글로 작성한다.

바야흐로 자바스크립트의 시대이다. 최근 2~3년 동안 자바스크립트는 가장 인기있는 언어 순위 1위를 유지하고 있고, 여전히 빠른 속도로 성장하고 있다. 10여년 전, 웹 표준이라는 개념조차 없을 때부터 프론트엔드 개발을 해 오던 나 같은 개발자에게는 정말 감개무량한 시대가 아닐까 싶다. 당시에는 개발 환경이라는 단어조차 부끄러울만큼 척박한 환경이었는데, 지금 쏟아져나오는 새로운 기술과 개발 도구를 바라보고 있으면 가히 풍요의 시대라고도 할 수 있을 것 같다.

babel/preset-typescript 플러그인을 만들기 위한 타입스크립트와 바벨 팀의 1년간의 공동작업 덕분에 타입스크립트가 훨씬 쉬워졌다.

지난주, VueConf Toronto에서 아이오닉 프레임워크(Ionic Framework)용 뷰(Vue) 지원에 대해 첫 공식 시사회를 열었다. 아이오닉의 개발자 Josh Tomas (@jthoms1)는 @ionic/vue 첫 알파 릴리즈에 대한 통찰과 개발자들한테 뷰 + 아이오닉 프레임워크가 안성맞춤인 이유를 공유했다. 그러나 이러한 본론으로 들어가기에 전에 아이오닉 프페임워크와 뷰의 역사를 먼저 이해하는 것이 중요하다.

성능이 매우 중요한 코드를 작성할 때는 알고리즘 복잡도를 생각하는 것이 좋다. 알고리즘 복잡도는 대개 Big-O 노테이션으로 표현된다. Big-O는 데이터가 많아질수록 코드가 얼마나 느려지는가의 척도가 된다. 예를 들어, 정렬 알고리즘의 복잡도가 O(n²)이라고 할 때, 50배 많은 개수의 아이템을 정렬하면 대략 50² 즉, 2,500배 느려지게 된다. Big-O는 정확한 수치를 나타내지 않는 대신, 알고리즘의 규모를 이해하는 데 도움을 준다. 아래처럼 Big-O 표현을 보면 얼마나 복잡한 알고리즘인지 알 수 있다.

자바스크립트의 객체와 함수가 참조형이라는 개념은 React의 성능에 직접적인 영향을 끼침에도 불구하고 많이 다뤄지지 않고 있다. 예를들어, 내용이 완전히 같은 함수를 두 개 만들더라도 두 함수는 절대 같지 않다. 다음과 같이 작성해보자. 다른 언어들을 사용해본 경험이 있다면 포인터라는 개념이 친숙할 것이다. 객체를 만들거나 기기의 메모리에 무언가를 할당할 때 마다 어떤 일이 일어나는 것일까?

2년에 가까운 시간 동안 4k의 커밋, 50회 이상의 프리 릴리즈, 그리고 많은 도움에 힘입어 바벨 7 정식 출시를 발표하게 되어 흥분된다.

프론트엔드에 대한 단위 테스트를 작성하도록 요청받았을 당시에만 해도 나는 Vue 애플리케이션을 테스트하는 것에 대해 전혀 몰랐다. 그래서 vuejs 테스트에 대해 알아보고 배운 것을 공유하고 싶다.

컴포넌트들이 항상 같은 구조로 되어 있진 않다. 그리고 때론 관리해야할 상태들이 많을때도 있다. 이런 문제는 비동기적인 방법으로 해결할 수도 있다.