sumi-0011 / took Goto Github PK

software-mansion/react-native-reanimated#3130

• 로그인, 회원가입의 테스트 코드 작성
• 로그인, 회원가입 코드 리팩토링

// /src/common/HOC/AuthHoc.tsx

import React, {ComponentType} from 'react';
import {isLoggedIn} from '@common/api/fireAuth';

export default function <P extends object>(Component: ComponentType<P>) {
  function AuthenticationCheck({...props}) {
    // if (isLoggedIn() === false) {
    //   props.navigation.replace('Auth');
    // }

    props.navigation.replace('Auth');

    return <Component {...(props as P)} />;
  }
  return AuthenticationCheck;
}

위와 같이 수정하고 재로그인, 회원가입 진행하면 됩니다. git 에 커밋할때는 당연히 원래대로 수정해주시면 되겠습니다.

• TCRCategoryScreen
• TCRInfoScreen
• CameraScreen

• 모달로 바꾸기

1. 누르면 자신의 위치로 돌아가는 버튼이 필요할 것 같아요.
2. 마커를 어떻게 움직일 수 있는지 모르겠어요. (못움직이나?)

• react-hook-form
• yup validation check

• 스택 네비게이션 분리
• 전체적인 코드 리팩토링

• 유저 정보
• 사용자 활동 시각화
• 등록된 쓰레기통 확인
• 등록된 쓰레기통 삭제
• 즐겨찾기 쓰레기통 확인
• 즐겨찾기 쓰레기통 삭제

테스트 공부는 잘돼가시나요. 학교에서 시킨다는 이유 때문에 맹목적으로 하지말고 우리가 지금 하고 있는게 대체 무엇인지 생각해보자구요.

테스트를 진행하는 이유 🤔

개발자도 사람이기 때문에 실수를 합니다. 테스트는 이런 실수를 발견하고 코드가 작동하는지 확인하는데 도움이 됩니다. 물론 우리들의 프로젝트처럼 작은 프로젝트를 처음 개발할 때는 실수가 안나올 수도 있겠지요. 하지만 개발을 완료하고 새로운 기능을 추가하거나 기존 코드를 리팩토링할 때는 어떨까요? (얼마 전에 제가 전체적으로 리팩토링을 했었죠.)

리팩토링을 하거나, 새로운 기능을 추가했을 때에도 기존 기능과 코드들을 모두 올바르게 작동해야 합니다. 그런데 이것을 어떻게 확신할 수 있을까요? 표면적으로 아무런 에러가 발생하지 않는다고 정말 아무 문제가 없는게 맞을까요? 개발자가 발견하지 못한 에러가 릴리즈 이후에 발견되면 어쩌죠? 심지어 그 에러가 원래 잘 작동하던 기능에서 발견되었다면..? 어쩌긴요. 핫픽스하느라 울며 겨자먹기로 밤을 새겠죠!

결국 테스트는 사용자 경험을 위한 것이기도 하지만 개발자를 위한 것이기도 합니다. Lint, Typescript 를 쓰는 것과 같은 맥락이지요.

React(-Native) 에서 테스트를 하기 전에..

앱의 테스트 가능성을 올리려면 UI는 UI 대로, 비즈니스 로직은 비즈니스 로직대로 테스트를 수행하는 것이 좋습니다. 컴포넌트에서 비즈니스 로직이나 로직들을 분리하라는 의미겠지요!!

또 테스트 방법론 중에는 많은 것들이 있는 것 같습니다. 흔히 알고 있는 TDD(테스트 주도 개발로, 실제 코드를 작성하기 전에 테스트 코드를 먼저 작성하는 방법론)도 이들 중 하나일 뿐입니다. 단지 요즘 많이 사용하는 것이고 성능이 확실하니까 많은 기업들에서 TDD를 추구하는 것이 아닐까 싶습니다.

하고 싶은 말은 우리가 꼭 테스트 주도 개발을 하지 않아도 된다는 것이랍니다. 실제로 테스트가 가능한 코드를 먼저 작성하고 테스트 코드를 작성하는 것이 틀린 방법이 아닙니다! 테스트를 대체 왜 하는지 몸소 깨닫고 테스트 코드를 작성하는 것이 익숙해질 때 TDD 같은 방법을 고려하는 것이 어떨까요? 우린 아직 테스트 초보잖아요~

@testing-library/react-native, Jest 로 테스트하기

테스트는 기본적으로 짧고 한가지만 테스트하는 것이 이상적입니다. it 함수는 테스트 함수입니다. 어떻게 사용하는지 볼까요.

it('given a date in the past, colorForDueDate() returns red', () => {
  expect(colorForDueDate('2000-10-20').toBe('red'));
}

it given a date in the past, colorForDueDate() returns red 가 하나의 문장으로 완벽한 것을 눈치채셨나요. 아래와 같은 키워드로 어떤 테스트를 수행하는지 분명하게 합시다.

1. given : 사전 조건
2. when : 테스트 중인 함수에 의해 실행되는 특정 액션
3. then : 예상되는 결과

jest 에서 it 과 test 함수는 이름빼고 다 똑같아요. 단지 첫번째 인자에 한글을 사용할 때에는 it 보다는 test 가 더 잘 와닿는 것 같아요.

단위 테스트?

단위 테스트는 개별 함수같은 코드의 가장 작은 부분을 테스트 합니다. 테스트 중인 객체에 dependency 가 있다면, mock 함수를 작성해야 할 수도 있어요. mock 함수를 사용하는 이유는 세 가지로 설명할 수 있어요.

1. 테스트가 느리고 불안정할 수 있다.
2. 해당 dependency가 항상 같은 결과를 리턴한다고 보장할 수 없다.
3. 서드파티 서비스를 현재 사용하지 못하는 상황일 수 있다.

통합 테스트?

통합 테스트에서는 각 단위들이 상호 작용하는 것을 테스트해요. 즉, 각 개발 단위들이 결합되고 함께 테스트되어 예상대로 작동하는 것을 확인하는 것이지요.

컴포넌트 테스트?

비즈니스 로직의 테스트 커버리지가 높고 정확하더라도, 컴포넌트 테스트가 없다면 사용자에게 의도와 다른 UI를 제공할 수도 있어요. 컴포넌트 테스트는 단위 테스트와 통합 테스트에서 사용될 수 있어요. 우리는 컴포넌트의 어떤 것을 테스트해야 할까요?

1. 상호작용 : 사용자와 상호 작용할 때 컴포넌트가 올바르게 작동하는지 확인하기 위해 (예를 들면 사용자가 버튼을 눌렀을 때!)
2. 렌더링 : 리액트에서 사용하는 컴포넌트 렌더링이 올바른지 확인하기 위해 (예를 들면 UI에서 버튼의 모양 및 배치같은 것!)

예를 들면 onPress 리스너가 있는 버튼이 있을 때, 버튼이 올바르게 표시되고 버튼을 클릭하는 것이 컴포넌트에서 올바르게 처리되는지 테스트하는 것이지요. 아래 코드를 확인해볼까요.

function GroceryShoppingList() {
  const [groceryItem, setGroceryItem] = useState('');
  const [items, setItems] = useState([]);

  const addNewItemToShoppingList = useCallback(() => {
    setItems([groceryItem, ...items]);
    setGroceryItem('');
  }, [groceryItem, items]);

  return (
    <>
      <TextInput
        value={groceryItem}
        placeholder="Enter grocery item"
        onChangeText={(text) => setGroceryItem(text)}
      />
      <Button
        title="Add the item to list"
        onPress={addNewItemToShoppingList}
      />
      {items.map((item) => (
        <Text key={item}>{item}</Text>
      ))}
    </>
  );
}

위 코드는 꽤 순순한 UI 컴포넌트라고 생각해요. 물론 addNewItemToShoppingList 와 같은 상태관리를 하는 로직이 View와 혼재되어 있지만 이 정도는 대부분의 상황에서 허용할 수 있는 수준이라고 생각해요.

자, 아무튼 우리는 위 코드에서 어떤 것을 테스트해야 할까요? props에 어떤 것들이 들어오고, state의 값이 무엇인지 테스트하지마세요! 이는 리팩토링으로 인해 테스트 코드가 쉽게 깨질 수 있고 다시 작성해야할 수 있어요. 결론은 UI가 잘 나타났고, 버튼을 눌렀을 때 예상되는 동작이 잘 되는지 테스트하면 됩니다!

test('given empty GroceryShoppingList, user can add an item to it', () => {
  const { getByPlaceholder, getByText, getAllByText } = render(
    <GroceryShoppingList />
  );

  fireEvent.changeText(
    getByPlaceholder('Enter grocery item'),
    'banana'
  );
  fireEvent.press(getByText('Add the item to list'));

  const bananaElements = getAllByText('banana');
  expect(bananaElements).toHaveLength(1); // expect 'banana' to be on the list
});

이 테스트 코드는 <GroceryShoppingList/> 컴포넌트가 주어졌을 때 유저가 item 을 list 에 추가하는 것을 테스트 합니다. 정확하게 하나의 기능을 테스트 하는 것이죠. 이 일련의 과정을 테스트 코드로 작성해봅시다.

먼저 fireEvent 는 jest에서 제공하고 changeText() 를 이용하여 해당 부분에 Text 를 변경할 수 있습니다. 유저가 input 에 무언가 작성했다고 가정하는 것이죠. 그 다음 press() 를 이용하여 Add the item to list 라는 Text 를 가진 버튼을 클릭합니다. 그 다음 getAllByText('banana') 로 바나나라는 텍스트를 가진 모든 엘레멘츠를 가져옵시다. 만약 이것의 길이가 1이라면 list 에 잘 추가했다고 예상할 수 있어요.

결론

제 생각에는 어떤 컴포넌트를 테스트하냐에 따라서 여러가지 테스트를 적용할 수 있을 거 같아요.

1. components : 이 디렉토리에 존재하는 컴포넌트들은 모두 View를 담당해요. 따라서 이 디렉토리는 컴포넌트 테스트, 단위 테스트, 통합 테스트를 적용합시다.
2. screens : 이 디렉토리에 존재하는 컴포넌트들은 많은 컴포넌트들이 사용되는 곳이니, 컴포넌트 테스트, 통합 테스트를 적용할 수 있을 것 같아요.
3. 비즈니스 로직 : 비즈니스 로직들은 전부 hooks로 빼서 따로 단위 테스트하는 게 좋을 거 같아요.

또 Jest 에서는 스냅샷 테스트를 제공해요. 말그대로 화면을 찍어서 개발자가 읽을 수 있는 코드로 확인할 수 있는 형태로 변환해요. 많은 글들에서 스냅샷 테스트를 권장하지 않아요. 그 이유는 다음과 같아요.

1. View가 변경되어 fail 된 것인지, 버그로 인해 fail 된 것인지 알 수 없다.
2. View가 변경되면 jest --update-snapshots 로 새로운 View 스냅샷을 업데이트 할 수 있어요. 이는 스냅샷을 업데이트하면 언제든지 스냅샷테스트가 통과될 수 있음을 의미해요.
3. 스냅샷은 이미 만들어진 UI 컴포넌트를 찍는 것이라 TDD 같은 방법론을 사용할 때에 스냅샷 테스트는 무조건 실패할 수 밖에 없어요.
4. UI는 정적이지 않아요. 자주 변경되는 UI 를 다루는 상황에서는 스냅샷 업데이트를 자주 할테고 이런 방식의 테스트는 너무 허술한거죠.

Source

react-native official docs
스냅샷 테스트의 단점

• 사용자 활동 시각화 데이터가 잘나오는지
• 즐겨찾기 항목이 잘 나오는지
• 즐겨찾기 항목 삭제가 잘 되는지
• 등록한 쓰레기통이 잘 나오는지
• 등록한 쓰레기통 삭제가 잘 되는지

localhost:4000의 경우

const uri = Platform.OS === 'ios'
    ? 'http://localhost:4000'
    : 'http://10.0.2.2:4000'

아이콘을 어디서 사용해야 할까
native에서 제공하는 아이콘도 있는데
이건 한계가 있고,... 더 있을거같은데 찾을수가 없다.

@sumi-0011 @BAESI NativeBase 쓴 프로젝트에서 Jest 로 테스트할 시에 반드시 아래와 같은 형식을 취할 것..!

import {NativeBaseProvider} from 'native-base';

const inset = {
  frame: {x: 0, y: 0, width: 0, height: 0},
  insets: {top: 0, left: 0, right: 0, bottom: 0},
};

function getComponent(props) {
  return (
    <NativeBaseProvider initialWindowMetrics={inset}>
      <LoginScreen {...props} />
    </NativeBaseProvider>
  );
}

이렇게 하지 않으면 Jest가 코드를 제대로 읽지 않고 스냅샷을 찍으면 아무것도 캡처되어 있지 않은 것을 볼 수 있음.

Originally posted by @jeonbyeongmin in #45 (comment)

• async await 고치기
• 스니펫 삭제

테스트 파일은 그냥 냅둘게요오

"file:///data/user/0/com.took/cache/Camera/4fdacfa2-a7b3-4687-8096-8337d6587547.jpg"

애뮬레이터안의 url로 저장이 되고, 서버로 전송해서 다른 폰에서 보게하려면 어떻게 해야할지를 모르겠어요..

• ViewProps Waring <- 일단은 무시!

파이어베이스 설정하기

• recoil적용
• 쓰레기통 카테고리 페이지 수정
• 카메라 페이지 수정
• 쓰레기통 등록 페이지 수정

버튼이 영역을 잡아먹는것을 수정해야함

• Profile 이 홈과 마이페이지에서 중복되는 부분을 수정
• 직관성을 올리는 디자인으로 변경

등록화면 진입 시 처음에는 기기의 GPS를 이용하여 초기 위치를 설정하나 사용자가 직접 세밀한 위치 조정이 가능하도록 하는 기능을 추가해야함

https://docs.nativebase.io/?utm_source=HomePage&utm_medium=Hero_Fold&utm_campaign=NativeBase_3

• mytook을 누르면 모달이 꺼졌다 다시 켜지는데 수정했으면 좋겠어요.

• 컴포넌트로 여러개 쪼개지 않고, 클래스이름이나 props로 제어(너무 세세하게 나누지 않고)
• 같은 일을 하는데 나눠놓지 말자
• 한 컴포넌트 안에는 하나의 의미를, 하나의 일만 하도록 (독립적이게)
• 스토리북처럼

설계에 대한 고민이 매우 많이 필요하다.
VAC로 여러 상황을 조금은 피할수있다.

넘나 어렵댱...

등록 시 같은 위치에 쓰레기통 등록을 막기 위해 주소의 중복을 확인하여 방지 할 계획 이를 위해 좌표값을 이용하여 주소를 알아내어 데이터를 저장해야함

사용할 API

• Reverse GeoCoding : 좌표 => 주소
• GeoCoding : 주소 => 좌표

• mock file 생성
• App-test.js 파일 초기화
• 프로젝트 절대경로 수정 (~/components* --> @components/* )

• firestore 기능 추가

• 즐겨찾기 기능 구현
• 버리기 기능 구현

즐겨찾기 기능

유저의 정보에 해당 쓰레기통의 id를 저장,
마이페이지에서 유저의 정보를 읽어서 즐겨찾기한 쓰레기통을 확인할 수 있도록 한다.

• 즐겨찾기를 클릭하면 user의 uid를 가지고 DB에서 user의 정보를 가져온다.
• user의 즐겨찾기리스트에서 해당 쓰레기통의 id가 존재하는지 확인한다.
• id가 존재하지 않는 쓰레기통을 클릭한 경우 즐겨찾기에 추가하고 끗
• 존재한경우에는 삭제하고 끗 (toggle)

버리기 기능 구현

• 쓰레기통을 클릭하면, 유저의 정보를 읽어 해당 쓰레기통을 언제 마지막으로 클릭했는지 확인한다.
• 마지막으로 클릭 한 지 일정 시간이 지나지 않은 경우에는 버리기버튼을 비활성화 하고
• (+ 좌표를 계산하여 유저의 위치와 해당 쓰레기통의 거리를 계산하여 일정거리 이상이면 버튼을 비활성화)
• 그렇지 않다면, 버리기버튼을 활성화 한다.
• 버리기버튼을 클릭하면
• 유저의 정보에 해당 쓰레기통의 아이디와, 현재 시간을 저장하고
• 유저의 클릭 횟수?를 하나 증가시킨다.

• user crud
• trashcan crud

• 로그인 화면 ui
• 회원가입 화면 ui

@sumi-0011

• auth 확인하고,
• 로그아웃 했을떄 정보가 남아있는 문제 픽스 (리로드 하는 형식으로 될거같음)
• 모달창 바꾸기
• 로그인 창 패딩

@BAESI

• 가득 찬 상태 프로그래스바 입력으로 교체

@jeonbyeongmin

• 카메라 사진 로컬 저장 -> 파이어베이스 Storage에 저장