RSpec 보안 개발 사용

12250 단어 Rails RSpec tech

안녕하세요!Offers가 운영하는 주식회사overflow의 꽃가루는 고통의 백엔드 엔지니어다.
미안하면 옛날에 시험 쓰는 거 싫어했는데 어쩔 수 없었어요 웃어요
요컨대 빨리 발매하고 가치를 제공하려는 욕망이 앞서면서 여분의 임무가 분배된 것 같아서...
하지만 지금은 시험이 없어서 발매가 무섭다.
만약 Production 발표 후 치명적인 오류가 발생했다면 리버트 사과와 같은 고통스러운 추억만 남길 뿐, 결과는 신속하게 부정적인 가치를 제공했다.
그래서 이번에 나는 시험을 좋아하지 않는다. 나는 시험 기술의 장점과 나쁜 점을 이야기할 수 있다면 좋겠다고 생각한다.
!
Rspec의 가져오기 및 기술 설명은 생략됩니다.

RSpec은

RSpec는 루비용 테스트 프레임워크입니다.

예제

아래의 간단한 방법이라도 테스트를 적으면 방법을 보증할 수 있는 동작이다.
아래의 견본 코드는 DB에서 이름을 얻어 전체 이름을 반납하는 간단한 것들이지만, 일부러 브라우저로 전체 이름이 잘 표시된 것을 확인하는 것은 번거롭겠지...(반응이 느린 사이트를 개발할 때 스트레스가 쌓여...)
user.rb

class User < ApplicationRecord
  def full_name
    "#{self.last_name} #{self.first_name}"
  end
end

user_spec.rb

require 'rails_helper'

RSpec.describe User, type: :model do
  describe 'full_name' do
    let(:user) { create(:user, first_name: '太郎', last_name: '田中') }
    it 'フルネームを取得すること' do
      expect(user.full_name).to eq '田中 太郎'
    end
  end
end

시험의 좋은 점을 쓰다

개인적으로 느끼는 은혜는 다음과 같다.

새 테이블 작성 등을 포함한 실현된 경우factory를 통해 위조 데이터를 제작하고 테스트할 수 있기 때문에 특별히 브라우저나rails console에서 데이터create

# usersテーブルを作成したが、まだ実データは存在しない場合
describe 'update_user_name' do
  let_it_be(:user) { create(:user) }
  it '名前を変更すること' do
    user.update_user_name(new_name: "hogehoge")
    expect(user.reload.name).to eq "hogehoge"
  end
end

를 진행할 필요가 없음

테스트 코드를 보면 이 기능의 규격을 알 수 있기 때문에 눈으로 봐도 영향 범위를 확인하기 쉽다

# シナリオテストなどの時に、機能の全体像を把握しやすい
describe 'メッセージ予約シナリオ' do
  let_it_be(:user) { create(:user) }
  let_it_be(:user2) { create(:user) }

  context '過去の時間で予約を試みている時' do
    it 'raiseエラーが発生すること' do
      expect{
        user.reserve_message(
          target_user_id: user2.id,
          text: 'おはよう',
          scheduled_at: Time.zone.now.ago(1,month)
        )
      }.to raise_error('過去の日時での予約はできません。')
    end
  end

  context '送信予定のユーザが退会した場合' do
    it '現在の予約件数が1減ること' do
      expect(user.current_reserve_messages.length).to eq 2
      user2.quit_service! # 「この退会メソッド叩かれた時に、関連する予約データは破棄される」という気づきがある。
      expect(user.current_reserve_messages.length).to eq 1
    end
  end
end

만약에 API의 응답이 테스트에서 예상을 얻었다면 프론트 데스크에 결합할 때 매우 수월할 것이다

다양한 용례를 고려한 테스트를 쓰기 위해 "아, 이 패턴을 잊었구나. PdM과 상의하자"는 발견

이 있었다.

모든 테스트를 통과한 후 발표하면 정신 상태가 더욱 좋아진다

코드 검사 시 방법이 테스트 보증을 받는 전제에서 처리할 수 있기 때문에 검사 원가를 낮출 수 있다

기존 처리와 결합한 개발 시 예상치 못한 오류 등을 사전에 피할 수 있음

기존 처리와 관련된 개발 시 의외의 오류 등을 사전에 피할 수 있다

나는 이것이 특히 좋은 점이 있다고 생각한다.
제품은 처음에는 매우 작았지만 성장함에 따라 코드의 양도 끊임없이 증가할 것이다.그때는 누구나 이전에 운행했던 기능에 문제가 생겼다는 것을 체험할 수 있었다.엔지니어들이 각자 자기가 실시한 기능 테스트를 진지하게 기술했기 때문에 영향 범위의 자동 검사를 실현하기 위해 새로 개발할 때 조마조마하지 않고 개발할 수 있다.

시험의 나쁜 점을 쓰다

은혜와의 절충이지만 개인적인 느낌의 단점은 다음과 같다.
안전한 상태에서 발표하는 게 좋을 것 같아서 다음은 어쩔 수 없는 일이라고 생각합니다.

테스트 코드를 설명하는 시간 증가

테스트 코드 설명에 익숙하지 않으면 포착에 시간이 걸린다

RSpec에서 추천하지 않는 기술 등 시계 및 기타 주의사항

추가 기능을 통해 기존 테스트 코드를 수정하는 작업 시간

테스트 파일 내의 기술은fat가 되기 쉬우므로 시간이 좀 걸린다

RSpec도 프로그램으로 실행 속도를 주의하지 않으면 발행까지 읽는 시간이 증가

시험 후 좋은 곳을 쓰기 시작하다

엔지니어 수가 증가해도 안정적인 기능 발표

빈대 대응 등 0은 아니지만 세밀한 대응을 위해 계획적으로 단거리 경주

팀 내부에 테스트 커버[1]를 고가로 유지하는 의식이 침투했다

TDD에서 API 내부 방법 테스트와 유닛 테스트를 실시하여 이전에 보지 못했던 과제와 알레르기 스미스를 격감시켰다

총결산

작업 시간 문제가 존재할 수 있지만 서비스를 사용하는 단말기 사용자가 편안하게 사용할 수 있도록 테스트 설명이 상당히 중요한 책임을 진다고 생각합니다!
시험을 열심히 쓰는 것을 추천합니다!

엔지니어 채용을 강화하고 있다

주식회사 오버플로우가 엔지니어를 모집하고 있다.Offers의 개발과 오버플로우에 관심이 있으시다면 꼭 신청하세요!분위기 파악을 위해 우선 부업부터 환영한다.

어쨌든 너의 의견을 듣고 싶다!이런 분들은 본사 CTO와의 캐주얼한 면담을 추천합니다.

※ 상기 채용은 본 원고 집필 시 정보이므로 열람 시 변경 사항이 있으면 양해 바랍니다