公式ドキュメント
- Introduction
- Core Components and Native Components
- Setting up the development environment
- あとはドキュメントの目次さらっと見たり、大事そうなページをさらっと見た
チュートリアル
- https://reactnative.dev/docs/tutorial
React Native導入ガイド - 環境構築からクロスプラットフォーム開発のメリットまでを理解する https://eh-career.com/engineerhub/entry/2020/02/06/103000

React Nativeについて

これまではReactでネイティブアプリ作れるクロスプラットフォームのライブラリくらいの認識だったけど、もう少しだけ解像度が上がって、ネイティブ部分とReact(JS)の間でUIライブラリやミドルウェアを提供してるイメージを持てた。

どっかにランタイムでReact NativeはネイティブのViewを作成するって書いてあったけど、ビルドした結果どういう出力になるのかを見ないとちゃんとイメージできないので、どっかで調べたい。

あとは、ネイティブモジュール？という仕組みで自分でネイティブコード書いて拡張したり、自作のUIコンポーネント作ったりできる。

普段の開発では、React Nativeには標準で提供してるネイティブコンポーネントがあるので、それを読み込むイメージ。

他には、コミュニティのいろんなコンポーネントがある。

reactnative.directory

Hooksは React Native 0.59 で導入されたっぽい。

ブラウザのAPIも提供してるけど、どこまでできるんだろう。

開発環境

React Native には、次の２つの開発ツールが用意されてるので最初に選ぶ

React Native CLI
Expo CLI

自分はプレーンなものを知りたかったので、React Native CLIからはじめた。

npx react-native init MyTestApp

プロジェクト名はハイフンとかだめで英数字だけ

iOS開発

今日はAndroidまで試すのが面倒だったので、iOSだけやりました。

iOSライブラリ管理ツール「CocoaPods」がいる
iOS周りの依存インストール
- iosにcdしてpod install

プロジェクト作成

プロジェクト作成については以下のドキュメント読んだら分かりました。まずこれちゃんと読んだほうが良さそう

https://reactnative.dev/docs/environment-setup

最初に自分のMacにXCode入れ忘れてハマりました
- あとはXCodeのインストール終わらなくてハマった
  - https://blog.kubou.net/archives/233/
その次はビルドしたら、BUILD FAILEDってなったので、v0.62にしたら直った
- 完全に以下の内容と同じ
- https://stackoverflow.com/questions/66062663/react-native-npx-react-native-run-ios-doesnt-work-after-initializing-the-proj

結構ネイティブ開発の知識必要そうだなーという印象。

アプリの起動

npx react-native start
- Metroというバンドラーを起動
npx react-native run-ios
- ビルドしてシミュレーターでアプリ起動
どっちも起動しないとシミュレーターで開発はできない

コンポーネント

以下の記事でリストで色々紹介されてたのでさらっとみた。

https://reactnative.dev/docs/intro-react-native-components

https://eh-career.com/engineerhub/entry/2020/02/06/103000

とにかくViewとTextはめちゃ使う。文字はTextに入れないとだめらしい。Webとはそこらへん全然違うな。

スタイル

StyleSheetを使うCSS-in-JSスタイルが基本。基本的にCSSだけど、使えないものもあるっぽい。

使えるプロパティはドキュメントを見る

Text · React Native

よく分かってないところ

まだ触りだけなので、ある程度のアプリを作るためのお作法とか、使うAPIとか設計とかは全く分かってない。あとはネイティブ部分は全く知見ないので、これから勉強しようと思いました。

あとはCSSはStyleSheet モジュール使ったけど、普通にライブラリ使ったりするのかとかも気になる。

とりあえず次はREST API叩いたり、ページ遷移するようなアプリ作ってみようと思います。

感想

WebでReact触っていたので、その延長線上で分かることが多かったです。アプリケーションを作るために新しく必要になる考え方はあまりなく、React Nativeの少しの違いや使うコンポーネントやAPIだけある程度覚えればやっていけそう。

公式チュートリアルがとても薄かったので、このチュートリアルやれば基本的なところ抑えれるよ。みたいなのが無かった。このあたりは他のライブラリだとだいたい用意されているので、気になった。ここらへんはReact分かってたら、あとはドキュメント見たらいいよ。くらいの温度感なんだろうか。

2021-02-10

PWAのオフラインサポート検出の改善

PWA

Improving Progressive Web App offline support detection

以下の記事のまとめやメモです。

developer.chrome.com

記事の内容

WebアプリをPWAとしてインストール可能かの条件として、Chromeではこれまで「fetch イベントを含むサービスワーカーがあること」となっていました。

それが、今後は「オフラインモード時のfetchイベントでHTTP ステータスコード 200を返すこと」となるみたい。

まず3月にリリース予定のChrome 89から、警告が表示される
- Lighthouseにもガイドが表示される
その後、8月にリリース予定のChrome 93から、適用される予定

※ 既にインストールされているPWAには影響しない

実装よりな話

これまでの判定について

これまで、PWA化はmanifest.jsonとほぼ空のService Workerをインストールすればいいので簡単だよ。と言われていましたが、今後はちゃんとオフラインサポートを実装する必要があります。

コード的に見ると、これまでは以下のService WorkerスクリプトでOKだった。

self.addEventListener("fetch", (event) => {});

今後の判定について

今後は、installイベントなどでCache APIを活用してリソースをキャッシュ。fetchイベントでオフライン時はキャッシュからリソースを返す。といった対応が必要になります。どこまでやるかはプロダクトによります。ある程度リソースをキャッシュしてオフラインでも動作するようにするとか。とりあえず静的なHTMLだけ返すとか。

最低限インストール要件を満たすためには、例えば以下のような処理は実装しないといけなそう。

const CACHE_NAME = "cache";
const OFFLINE_URL = "/";

self.addEventListener("install", (event) => {
  event.waitUntil((async () => {
    const cache = await caches.open(CACHE_NAME);
    return cache.add(OFFLINE_URL);
  })());
});

self.addEventListener("fetch", (event) => {
  event.respondWith(
    (async () => {
      try {
        const networkResponse = await fetch(event.request);
        return networkResponse;
      } catch (e) {
        const cache = await caches.open(CACHE_NAME);
        const cachedResponse = await cache.match("/");
        return cachedResponse;
      }
    })()
  );
});

2020-12-31

2020年の振り返り

まとめ

2020年

2020年を振り返っていこうと思います。振り返りを毎年継続して書いていくことで、その記事を見れば自分の1年間の活動を思い出せたら良いなと思ってます。

f:id:toshi-toma:20201231161310j:plain — ほとんど外出してないので、今年っぽい写真がなかった(写真は松山城からの景色)

去年の振り返り

toshi-toma.hatenablog.com

2020年
仕事
複業
アウトプット、イベント
開発、学習
OSS
英語
プライベート
- 今年買ったもの
さいごに

仕事

今年はサイボウズに新卒で入社して、4年目の年でした。

仕事として、そこまで大きな変化はなく、去年(2019)からやっていた内容に継続的に取り組んでいました。

blog.cybozu.io

主にフロントエンドの脱レガシーに取り組んだ1年だったので、そこでの知見をもとに、チームメンバーでWEB+DB Pressで執筆したりもしました。

blog.cybozu.io

業務としては、それ以外にも探究活動や社外向けのイベント開催などにも取り組みました。探求活動では、Service WorkerやSvelte、ASTベースのリファクタリングなどに取り組みました。

フロントエンド以外だと、引き継ぎエンジニア向けの社内イベントの企画と運営などにも取り組んでいます。今年の10月頃に開催された、OSCでは、そういった取り組みについても話しました。

エンジニアによるエンジニアのための社内イベントの企画 / Planning internal events by engineers for engineers - Speaker Deck

複業

TechTrain

引き継ぎTechTrainでフロントエンドのメンターをやってます。Reactの相談が多いけど、FirebaseやVue.jsやCSSやTypeScript、Next.js、キャリア周りの相談もあって面白いです。自分の知らない範囲での相談もあるので、面談前に軽く勉強したりするので、いいきっかけになったりします。

techbowl.co.jp

フロントエンドの開発

4月頃から新たに、フロントエンド開発の複業をはじめました。ReactとTypeScriptをベースにしたプロジェクトです。複業では、本業のサイボウズでは経験できない多くのことに取り組めて、とても良かったなと思います。本業だと、どうしても経験できる領域やステージに偏りがあるので、複業を通して新しいプロジェクトのベースを作ったり、一人で技術選定したり、一人でもくもくとコードを書いたり、チームメンバーのレビューをするなどを経験できました。

月に40時間をコンスタントに複業に当ててるので、プライベートの時間がほとんど確保できないのは、結構辛かったです。

個人事業主と確定申告

本格的に複業に取り組む時間の割合が多くなったので、開業しました。ネットで色々と調べたり、チームメンバーに聞いたりしてなんとかできました。

経費にできるものなど、なんだか大人になった気分です。

toshi-toma.hatenablog.com

アウトプット、イベント

今年の1月頃は普通に勉強会を開催していました。

Ehime.js #4 初心者歓迎 LT会 - connpass

それがコロナの影響で、いっきにリアルで勉強会を開催できなくなり、オンラインにシフトしていきましたね。地方に住むエンジニアとしては、YouTubeで勉強会を見れるので、とてもありがたかったです。

去年はアウトプット重視で登壇や記事の執筆などにも注力してましたが、今年はほとんどできなかったです。登壇はコロナの影響で、カンファレンスや勉強会の機会がとても減った & オンラインになったあとはモチベーションが下がってました。

もうちょい記事など書いたりしたかったけど、複業で時間があまり確保できなくて、ほとんどアウトプットしない年になりました。

その中でも、オンラインで何度かだけ登壇する機会がありました。

フロントエンドのエコシステム / Frontend Ecosystem - Speaker Deck

Service Workerとは、それを使ってできること / what-is-service-worker - Speaker Deck

自分は開催するモチベーションがなくなってるので、オンラインでも継続的に勉強会を開催してくれてる人には感謝です。

開発、学習

引き続きReactベースのフロントエンドの事を勉強してました。今年はYouTubeやFrontend Mastersといった動画コンテンツを使うことが多かったです。

最近、周りのエンジニアの影響でLeetCodeも始めました。単純に問題を解くのが楽しいので、趣味としてもいいなと思いました。アルゴリズムやデータ構造周りは来年から本格的に勉強しようと思ってます。

OSS

今年の前半は時間もモチベーションもあったので、OSSにPRを送ってみたりもしてました。

toshi-toma.hatenablog.com

複業を始めた頃には、プライベートの時間は複業と英語の勉強でいっぱいいっぱいになり、OSSに取り組むこともしなくなりました。来年は再開したいです。

英語

今年注力したことの一つに英語学習があります。年始のタイミングでTOEICを受けて、自分のスタートラインを確認して、そこからは毎日コツコツ英語に取り組んでいます。

モチベーション維持のためにレアジョブをほぼ毎日やって、基礎を固めるために英文法や英単語、リスニングなど取り組みました。いかに習慣化するかを意識しました。好きなテーマの英語コンテンツに触れるという意味でYouTubeの存在は大きかったです。

11月頃からモチベーションが下がり気味で、時間に余裕が生まれるまではペースをおとして緩く取り組もうと思っています。

プライベート

プライベート的には在宅勤務が基本になり、1年間のほとんどを家で過ごしていました。家での生活が快適になるものを買ったり、自炊をしたりしました。

ただ、自粛の影響で、これまで継続的にジムに行っていたのがなくなり、家で少しの筋トレに変えました。

ご飯を食べる時間は動画を見ていて、SUITSやウォーキングデッドといった海外ドラマを見たりして過ごしてました。

あとは、将来のことも考えて資産運用について調べて、始めたりもしました。来年はiDeCoも始めようかなという感じもあります。

来年はより快適な部屋を求めて引っ越し予定です。もう少し愛媛を満喫できそうです。

今年買ったもの

ロボット掃除機

Ankerのロボット掃除機を買いました。掃除機をかけなくても十分綺麗になるには最高でした。ただ在宅勤務と相性が悪いのが最近の悩みです。

Bluetooth防水スピーカー

お風呂では音声コンテンツを聞いてるので、防水スピーカーでより快適になりました。

スタンディングデスク

オフィスでスタンディングデスクを使っていましたが、在宅勤務中もスタンディングデスクを使いたかったので、FLEXISPOTのスタンディングデスクを買いました。満足です。

iPad Air

初のiPadを買いました。スマホとPCあるから使わないかなーと思い敬遠してましたが、いざ買ってみると、利用シーンが多くてびっくりしました。最近はだいたいのことをiPadでやってる気がします。

AirPods Pro

体験としてとても良い。あと気軽なノイズキャンセリングなのも良い。

Mac mini

M1 Macです。在宅が多いので、デスクトップにしました。

プロジェクター

大画面でドラマや映画を見たいけど、大きいテレビは場所をとる & 高いので、プロジェクターを購入してみました。2万円くらいだったけど、映像は綺麗で最高でした。

メガネ

これまでは常にコンタクト生活でしたが、メガネを作りました。画面を見る時間が長く、偏頭痛持ちだったのですが、メガネだと目への負担が小さく、頭痛になる率が減りました。特に問題もないのでメガネで生活するようになりました。

Notion

モノではないですが、今年からNotionを有料で使っています。ノート系だけではなく、タスク管理もTodoistからNotionに移行しました。基本的に大体のことをNotionに書いてます。

さいごに

今年はコロナの影響で生活スタイルが家を中心に変わりました。だからこそ、これまで以上に快適な部屋作りに注力したし、複業や英語学習などにも時間を使うことができました。

エンジニアとしては、引き続きフロントエンドを中心にやっていくと思いますが、来年はもうちょい挑戦する年にしたいです。

今年、2020年もありがとうございました。

2020-04-12

開業と初めての確定申告 in 2020

副業まとめ

今年、始めて確定申告と開業を経験したので、備忘録として残しておく。自分は専門的な知識があるわけではないので、間違った情報もあると思うので、その点はあしからず。

開業と初めての確定申告

去年、副業を始めた。

年間の所得が20万円以下だったので、「確定申告しなくていいのか〜」と思ってました。

www.freee.co.jp

ふと気になって調べてみると、副業20万円以下＝確定申告は不要は正解。だけど住民税の申告は必要らしい。

住民税のみの申告なら、確定申告をしなくてもいいが個別に申告するくらいなら確定申告をすれば、自動的に住民税にも反映される + 余分に払った源泉徴収が返ってくるかも。ということで確定申告をすることにしました。

確定申告

特に経費があるわけでも無かったので、確定申告は会計ソフトを使うことでとても簡単でした。

まずは「会計freee」を契約した。

その後は、会計freeeに去年の収入情報を登録したのち、freee上で「確定申告」の流れにそって進めて、必要事項を入力したら書類が作成された。

support.freee.co.jp

入力にあたって、本業の源泉徴収やふるさと納税の受付書が無いとだめだった。

ふるさと納税で、ワンストップ特例制度の申請をしていたけど、これは確定申告をすると無効になるので、確定申告でふるさと納税に関しても入力しないとだめだった。

www.satofull.jp

書類が作成されたら、印刷して税務署に書類を提出したら終わり。提出も5分くらいで終わった。

マイナンバーカードを持ってると、オンライン上で完結できるらしいので来年はそれでやりたい。

開業

確定申告とは別で、開業の申請もしました。

4月から新しく副業を始めたので、このタイミングで開業したほうがいいのかを調べた結果、することにしました。

www.freee.co.jp

主にポイントは、青色申告することで控除が受けられるのが大きいらしい。

青色申告にすると帳簿など書類作成が大変らしいが、会計freeeを使ってるとだいぶ簡単なので、問題にはならないらしい。

開業もとても簡単で、「開業freee」に必要事項を入力すると書類が作成されるので、印刷して税務署に提出するだけだった。

開業届けと同時に、青色申告するために必要な青色申告承認申請書も用意できるので一緒に提出した。

経費に関しては、事業に関わるものなら経費にしてよくて、会計freeeに支出として登録すれば良い。ただ、領収書などは印刷して保管しておく必要があるので注意が必要そう。電子帳簿保存の事前申請をすれば、電子でもいいっぽい。

さいごに

始めてのことで、いろいろと分からないことが多かった。

だけど、freeeが分かりやすかったり、ネットにたくさん記事があったり、YouTubeで動画をみたりして学んだらなんとかなった。

2020-02-21

「What's coming in ESLint v7.0.0」を読んだ

What's coming in ESLint v7.0.0

https://eslint.org/blog/2020/02/whats-coming-in-eslint-7.0.0

What's coming in ESLint v7.0.0の画面キャプチャ

ESLintの次のメジャーバージョン「7.0.0」に入る機能が決まったようです。

社内用に日本語でのまとめを書いたので、せっかくなのでブログとしても公開します。

※ ESLintは日本人のTSC(Technical Steering Committee)の方がいて、いつもQiitaに解説記事を投稿してくれるので、もしその記事が出たらそちらを見るほうが良いです。

v7.0.0の開発は以下のGitHub Projectで確認できます。

https://github.com/eslint/eslint/projects/6

✋Dropping support for Node.js v8.x

Nodeのv8.xは去年の12月でEOLになったのでESLintもv7のタイミングでNode v8.xのサポートを終了

"engines": {
-    "node": "^8.10.0 || ^10.13.0 || >=11.10.1"
+    "node": "^10.12.0 || >=12.0.0"
}

Deprecating Node.js/CommonJS-specific rules

コアのルールが見直され、Node.js/CommonJS特有のルールはeslint-plugin-nodeに移行される。

ESLint本体で管理されている以下のルールはコアのルールとしてはdeprecatedになり、eslint-plugin-nodeに移行されます。

callback-return
global-require
handle-callback-err
no-buffer-constructor
no-mixed-requires
no-new-require
no-path-concat
no-process-env
no-process-exit
no-restricted-modules

将来のメジャーリリースでコアから削除される予定なので、eslint-plugin-nodeに移行しておいてね。という話

ESLint class replacing CLIEngine class

ESLintのAPIを非同期APIに移行。

これまでESLintをNode.jsから利用する場合、CLIEngineクラスを利用していました。(このクラスを使ってエディタのプラグインやESLint組み込みのツールなどが作られてる)

ただ、CLIEngineクラスは同期APIなので、並列でファイルをチェックやECMAScriptモジュールのロードなど新しい機能のブロッカーになっていました。

そこで新しく非同期APIであるESLintクラスへの置き換えを進めていくようです。

ESLintクラスは最初CLIEngineの単なるラッパーとして作って、段階的に非同期メソッドを実装していき、最終的に、ESLintクラスとCLIEngineクラスが完全に分離されるっぽい。(このあたりの詳しい実装はよく分からなかったので曖昧です)

v7.0.0では、CLIEngineクラスはdeprecatedになる。将来のメジャーリリースでCLIEngineを削除する予定

Descriptions in directive comments

/ eslint-disable **/に説明がつけれる

/* eslint-disable no-new -- this class has a side-effect in the constructor. */

Warnings for using ~/.eslintrc

v6.7.0で非推奨になっているホームディレクトリでの.eslintrc(設定ファイルが見つからない時にホームディレクトリの設定が適用されるやつ)がv7.0.0だと警告されるようになる。

ホームディレクトリでの.eslintrcはv8.0.0で削除予定。

Updating the base path when using --config or --ignore-path

--configや--ignore-pathオプションで指定した設定ファイルやignoreファイルのbase pathがworking directoryになる。これまでは、オプションで渡したファイルの場所だったっぽい。

Plugins loaded from config file directory

ESLintのshared-config(eslint-config-xxx)からpluginを直接読み込めるように。

https://eslint.org/docs/developer-guide/shareable-configs

v7.0.0以前ではプラグインの読み込みはESLintがインストールされている場所(v5.x)だったり、working directory(v6.x)でした。

v7.0.0からはリント対象のファイルに最も近い設定ファイルを基準にプラグインが読み込まれるようになるっぽい。

これまでeslint-config-xxxのpackage.jsonでは依存してるpluginはpeerDependenciesに指定して利用側でpluginをインストールしていたが、dependenciesに指定することができるようになる。

File extensions in config files

v7.0.0以前では、ディレクトリを指定してリントを実行した場合、*.jsファイルだけが対象になっていた。それが設定ファイルのoverridesセクションのファイル指定にマッチするファイルがリント対象になる。

React、Vue.js、TypeScriptなど、.js 以外のファイルを利用している場合に便利です。

Updated default ignore patterns

ESLintのデフォルトのignore patternに以下の要件を追加

unignore .eslintrc.js
unignore /bower_components/*
ignore node_modules/* in subdirectories

Stricter RuleTester

ESLintのルールのテスト用のAPIであるRuleTesterにいくつか追加されている。

https://eslint.org/blog/2020/02/whats-coming-in-eslint-7.0.0#stricter-ruletester

Fails if a rule uses the nonstandard node.start or node.end properties, which may not be provided by all parsers that ESLint supports.
Autofix rules must test the output of their fixes.
Tests where the code has a syntax error will now fail.
Tests fail if the test specification contains unknown properties.

いくつかありますが

Autofix rules must test the output of their fixes.

Autofix時の結果をテストで書いてないplugin多いから、対応大変かも。

Installing preview releases of v7.0.0

この内容はnext tagでインストール可能です。

$ npm i eslint@next --save-dev

2020-02-17

TDD Boot Camp in 愛媛に行ってきました & Testingについて

TDD Boot Camp in 愛媛に行ってきました

先日(2/15)に愛媛にて開催された「TDD Boot Camp in 愛媛」に行ってきました。

会場はサイボウズ松山オフィスです！

agile459.connpass.com

当日の様子 togetter.com

TDD Boot Camp in 愛媛に行ってきました
- 内容
- テスト駆動開発
Testingについて
最後に

内容

内容としては、TDDの伝道師、和田卓人さん (@t_wada) によるテスト駆動開発についての講演＋ペアプログラミングによるTDD実習でした。

午前中の講演では、テスト駆動開発と何か。から始まり、ライブコーディングで実際にTDDを実践する様子を見ることができました。

t-wadaさんによるテスト駆動開発のライブコーディング見れるの最高すぎる。。。
#tddbc
— Toshihisa Tomatsu (@toshi__toma) 2020年2月15日

t_wadaさんがどのような思考プロセスで、どんな順番でTDDを実践するのかを見ることができ、とても勉強になりました。

午後は、言語によるペア(自分はJavaScript)を組んでのTDD実習でした。実習の中ではコーディングした後にみんなでコードレビューなども行いました。

インプット(午前中の講演)からアウトプット(ペアで実習)の流れがとてもスムーズで理解が深まりました。

テスト駆動開発

Boot Campに参加することで学んだテスト駆動開発のポイントをざっと書いておきます。

まず何のタスクから取り組むか？

テストが書きやすいという基準＋重要度で考える。

聞いただけだと、あまり実感がわかなかったですが、実習中にこの重要性に気づきました。 TDDの中で出てくるRedからGreenまでのプロセスをいかに早く辿り着くかで、その後のタスクの進めやすさに影響するので、まずはテストが書きやすいか。という軸で考えることが大事だと思います。

まずは一歩一歩

t_wadaさんによるライブコーディングや、考え方などから、コーディングにおいて一歩一歩進む姿が印象的でした。

普段は焦って、どこまで確実に動作していて、どこが問題になりそうなのか。未知の状態で突き進むことが多いですが、まずは正しく失敗することを確認したり、簡単だけど正しく成功させることができることを確認することが重要。

問題を小さく切り分けることが重要。

まずは簡単に失敗させて、テストを実行させるスタート地点にたっているか確認する。
ライブラリや設定ミスとか、いろいろあるからね。#tddbc
— Toshihisa Tomatsu (@toshi__toma) 2020年2月15日

コードの品質

テストを書いて、テストが落ちてないからOK。で終わらずに、コードの品質について常に考えることが重要。

テストケースを見て、プロダクトコードの振る舞いを過不足なく簡単に理解できるようなテストコードやテストケースの品質。Red-Green-Refactoringのサイクルの中で、Greenにした後にはどこか改善できるポイントはないか考えるなどなど。できることはたくさんありそう。

何より、テストを書いたら目的達成。ではなくコードの品質を高めることを常に意識する。

テストケースは後から別の人が見たときに仕様書レベルでプロダクトコードを理解できるように意識する & テストコードもプロダクトコードレベルに品質の高い状態にするぞ
#tddbc
— Toshihisa Tomatsu (@toshi__toma) 2020年2月15日

Testingについて

TDD Boot Campに参加するということで、事前にTestingについて、フロントエンドにおいてのテストについてインプットをしておきました。

ここからは事前にインプットしたTestingについて書いていきます。

事前に見たもの

Jest | Getting Started
- https://jestjs.io/docs/en/getting-started
Clean code that works - How can we go there?
- https://t-wada.hatenablog.jp/entry/clean-code-that-works
明日からはじめるテストのあるフロントエンド開発
- https://speakerdeck.com/mukai21/ming-ri-karahazimerutesutofalsearuhurontoendokai-fa
An Overview of JavaScript Testing in 2019
- https://medium.com/welldone-software/an-overview-of-javascript-testing-in-2019-264e19514d0a

フロントエンドのテスト

使う可能性のあるテストツール

Jest
Cypress
react-testing-library
react-hooks-testing-library
Storyshots
reg-suit
(Enzyme)

テストの種類(Reactでの例)

Linting, TypeCheck
- ESLint, Stylelint, tsc
Unit Tests
- 関数やクラスなどが対象
- 入力に対して出力が期待するものか
- ex: Jest, react-testing-library etc
Integration Tests
- 機能が対象
- 複数のユニットテストでの手順をテストする
- モックを可能な限り利用しない
- ex: Jest, react-testing-library etc
E2E Tests
- アプリケーションが対象
- ブラウザを制御してシナリオがどのように機能するかをテストする
- 内部構造は無視してブラックボックスのようにチェック
- ex: Cypress, Selenium
Accessibility Testing
- ex: pa11y
Visual Regression Testing
- ex: backstop, reg-suit

Testing

調べる中でTestingについて気になったポイントを書いていきます。

テストコードの品質

テストコードのクオリティを下げると将来メンテナンスできない大量のコードを持つことになるので、テストコードも品質はプロダクトレベルで書くべき。

Testingの層

テストピラミットやTesting Trophyなど考え方の参考にできる。

ただしUnit TestやIntegration Test、E2Eなど人によってどんなテストを書くかは違うので、保守や実行コストなどを考慮して、3つに分解して、各層ではどんなテストを書くかをチームで議論する。

Integration TestとUnit Test

E2E、IntegrationとUnit Testで、どのテストを書くのか迷ったときに、1つ参考にできそうだったのが、内部品質と外部品質の観点。 E2Eは外部品質を担保するし、Unit Testは内部品質を担保してくれる。integrationは中間くらい。それぞれ担保できるものが違うので、何を保証したいか考える。

なのでIntegrationやE2Eでカバーすれば機能的にOKでしょ。と思ってもそれを続けるとコードの内部品質が落ちる。

常にTDDでやるのか

もちろん向き不向きがある。例えばフロントエンドだと期待する結果がわからなかったり、まずは作ってみないとわからないものもある。必ずテストファーストではない。プラクティスとして持てると良い。

まずは実装してみて、その日のうちとか、その週までに十分な観点を入れたテストを追加するでも良いし、フロントエンドはある程度はE2EやIntegrationでカバーして、複雑そうな部分だけUnitテスト書くでも良さそう。

最後に

今回のTDD Boot Campはt_wadaさんにTestingやテスト駆動開発についてその場で聞いて、インプット→アウトプットをすることで理解を深めることができる最高の場でした。

思考や取り組み方など今後のエンジニアリングで参考にできそうものが多かったです。

主催のAgile459さん、そしてt_wadaさん、参加された皆様ありがとうございました！