radioc@?

レディオキャットハテナ

【勉強会メモ】関西Node学園 梅田キャンパス 1時限目

nodejs.connpass.com

Node.jsのユーザーグループによるNode学園が関西で立ち上がって初開催でした。学生の人もけっこういたりで、盛り上がりを感じました。ちなみに私は個人的に使うレベルなので勉強したいと思って参加してきましたが、あまり詳しくないのでなんとか話についていってメモして帰ってきたという感じです…

ついこないだまで4や5を使っていた印象なのにもうすぐ10が出るとのことでフロントエンド界隈の時間の流れは本当に速いと感じます。ユニットテストの話はJSに限らない気もしますが、速い時間の流れに置いていかれたレガシーなコードも少しずつテストを書いていこうと思える内容でした。

春からはじめる新しいNode.js - Node.js v10

@shisama_さん

speakerdeck.com

※遅刻してしまったので途中からのメモです。

新しいNode.jsを実習

最新のNode.js

Node.js ビルド

  • Makeするだけ
  • 時間もそんなにかからない

さらに新しい機能を試す

  • フラグをつけると使える
  • node --experimental-modles

harmonyフラグ

  • EcmaScriptの機能を使えるようにする
    • shipping:リリース済み(フラグなしで実行可能)
    • staged:ほぼ完成 --harmonyフラグ
    • in progress:開発中
  • node -v8-options で使える機能を確認

Node.jsに実装されていない機能

  • Babelでトランスパイル
  • EcmaScript 全機能をカバーしているわけではない

まとめ

  • Node.jsのサポート期間を意識しよう
  • Node.js v10は来週リリース

TypeScript + Express

@kamiyamさん

www.slideshare.net

TypeScript

⇒大きめのシステムでJSより少しきっちり使いたい時などに使われる言語

TypeScript導入(not Express)

npx

qiita.com

  • tsconfig.json …設定
  • any …なんでも使える型⇒基本的には使わない

型定義を準備する

  • 文字通り型のないJavaScriptに型を定義する
  • 型定義 (d.ts) ファイルを作成(参照)する
  • 多くは@types/xxxから探すことができる
  • 自分で定義することもできる
    • tsファイル内 types/*** で定義
  • interface使える
  • enumも使える

ES2017使いたい

  • コンパイルオプション使う
  • tsconfig.json
    • compilerOptionstarget"ES2017" を指定

tslint

  • 入れたほうが幸せ

TypeScript+Express

TypeScriptへの置き換え

Quick Start · TypeScript

github.com

※参考

gist.github.com

Babel7.xで変わること

@mochiya98さん

Babel7.xで変わること - Google スライド

主な破壊的変更

  • scoped modleへの変更
  • es20xx系のプリセットが非推奨
    • JSではなくブラウザを基準に指定
  • scoped modlesはpresetがフル表記に
  • カンマ区切りのpresetsがエラーに

追加機能

  • .babelrc.jsのサポート
  • TypeScriptのサポート

細かい変更を知るには

  • Planning for 7.0
    • 若干古いので注意
  • Nearning the 7.0 Release
    • この記事を観てわからなければPlanning~を見る
  • Upgrade to Babel7
    • 意向メインならここを見る
  • 次のリリースであるBabel7の主な変更点まとめ - 技術探し
    • より細かい情報

最新の情報はBabel公式ブログを見れば安心

多くのプロジェクトに対応するのは大変

JavaScriptユニットテストの理想と現実

きりん@sota1235さん

speakerdeck.com

  • 現実のつらみからテストを書ける状態にもっていく話

テストの必要性

  • なぜテストは必要か?
    • 品質担保のため
  • 品質とは
    • 意図したとおりに動作するか
    • きれいなコード
    • 想定していない入力に耐性があるか

ユニットテスト

  • あるモジュールが単一の責務を果たしているかをテストする
  • 最小粒度でのテスト
  • モジュール単位のテスト

責務毎にテストを分ける

  • 1テストケースがシンプルになる
  • モジュールが責務ごとに分かれることが強制される

汚いコードはテストが書きづらい

  • テストを書けるようにするとコードがきれいになりやすい

なぜテストを書きづらいか

  • requireしたら即実行
  • イベントリスナに渡されるfunctionがいろんなことをしている
  • 分岐の数の掛け算だけテストケースが増える
  • 不確定要素が多い
  • APIとの通信DOM APIのコール

全てのフロントエンドのコードがきれいって早々ない

現実との戦い

テストが書くのが難しくテストを書く文化もない

なぜテストが浸透していないのか

  • フロントエンドのコードをモジュールでばらして書けるようになったのがここ数年
  • フロントエンドの要件事態が複雑化
  • 複雑化したロジックを保守する必要性が増した

フロントエンドis カオス

  • ステートフルな世界
  • UIとロジックの2つの世界
  • 様々な外部要因

現 実 is カオス

  • レガシーコード
  • jQuery 1.x.0とか...

どう立ち向かうか

書いて終わりではない

  • 運用、保守する必要がある
  • ロジックが変わればテストも書き換える
  • コスパが大事

コスパを考える

  • テスト対象のモジュールが変更される可能性が高くないか
  • テスト対象はロジックでなくUIではないか

例えば

  • クリックされたら消費税を計算」
    • 計算ロジックならテストしてよさそう
  • jQueryで動的に生成されるDOMのclass名
    • いろんな都合でclass名が変わる可能性がある

テストを書く場所の勘所

  • UIのテストは無駄になることが多い
    • E2Eテストが難しいと言われる所以
  • コアのロジックは変わることが少ない
  • 使いまわせる粒度に保てば再利用性も上がる

モジュールを切り出す

現実はだいたい多くの責務を持った何かがある

  • ユーザーインタラクションとロジックを分離する
    • 1つのイベントリスナに詰まっていたものをまずイベントリスナとそれ以外で分ける
  • ロジックを分離する
    • ロジックから2つのロジックを切り出す

つらい現実に立ち向かうには

  • 今あるコードを紐解いていく
  • 紐解く時の鍵はUIとロジック
  • 紐解いてfunction化、module化したものにテストを追加していく
  • 簡単なところから少しずつ

テストを書くという文化

  • テストを書く文化がないなら積極的にアプローチ
  • 1つ簡単なサンプルがあればみんな真似する

mochaのトレーニングリポジトリ

github.com

おまけ:次のつらさ

importをモックする

speakerdeck.com

無理せずflowtypeを導入していく

まいける@h_michael_zさん

speakerdeck.com

Flowの導入

TypeScriptとの違い

  • FlowTypeはFBが作っている
  • アノテーションをJSに書いて使う感じ

  • babel 使い

    • npm install
  • そうでなければ
    • package.jsonに書く

npm run flow で実行

最初に読む

  • 使い方:公式のusage
  • 型付け:公式のtypes
  • Try flowで動かしながら読み進める
  • flow-type-cheat-sheet
  • Editorの設定
    • flow-language-server

型をつけ始める

  • はじめは無理に細かく型付けをしない
    • Primitive,Array,Union,Object,Mixedでかける範囲で型を付ける
    • Anyはなるべく使わるMixedかObjectを使う
  • ObjectのpropertyがOptionalかどうか値がMaybe Typeかどうかどちらにもしない
    • 慣れれば型の未定義なものでも1ファイル10分くらいで型付が終わる

3rd partyのライブラリにも型をつけたい

  • flow-typedを使ってみる
  • TypeScriptでいうDefinitely Typed

Flowのupgradeの話

  • 一気にバージョン上げるのはつらいのでこまめに上げる
  • 型安全を手に入れたいだけなので新しいfeaturはどうでもいい
  • バージョンごとにlikely to cause new Flow errosがある
  • バージョン上げるごとにより安全になる