ソフトウェアのテストを書くのが嫌になる瞬間 第4位

ソフトウェアのテストを書くのが嫌になる瞬間、今回は第4位です。

テストを書くのが嫌になる瞬間 第4位 : テストの文脈を見ないで落ちたテストのみ修正しているのをみたとき

今回は10コマ漫画でお送りします。

なお、以下単に”テスト”と書いた場合は、テストコードのことを指し、CIツールなどで自動実行されるものを指します。また、単に"コード"と書いた場合には、プロダクションコードを指します。 また、単体テストよりもエンドtoエンドのテストを厚く書く職場で働いています。

大体こうなるよね。

とにかく落ちたテストしか見ないのです。落ちたテストが書いてあるファイルは見てほしいし、少なくとも前後のテストケースくらいは確認してもらいたいものですが、見ないのです。ちゃんと元のテストコードには

説明	値	期待値
最小値 - 1	2	エラーが出る
最小値	3	登録できる
最大値	10	登録できる
最大値 + 1	11	エラーが出る

のように説明も書いてあるんですよ(上記だと期待値が適当ですが実際はちゃんと書いてあります)。全然読まれてない。

念のため書いておくと、下記のように直すのが正しいです。

説明	値	期待値
最小値 - 1	2	エラーが出る
最小値	3	登録できる
最大値	20	登録できる
最大値 + 1	21	エラーが出る

上記漫画の重症例はソフトウェアのテストを書くのが嫌になる瞬間 第1位と同じメンタリティですね。とにかくテストが通ればよいという考えのようです。

誰ですかテストは仕様書だと言ったのは。修正漏れたままマージされてしまったら、

説明	値	期待値
最小値 - 1	2	エラーが出る
最小値	3	登録できる
最大値	10	登録できる
最大値 + 1	21	エラーが出る

もしくは

説明	値	期待値
最小値 - 1	2	エラーが出る
最小値	3	登録できる
最大値	10	登録できる
最大値 + 1	11	登録できる

になりますよ。これ、"仕様分からないからソース見なきゃわかんない"に陥るパターンではないですか。

仕様変更での修正漏れは、レビューでもうっかりすると見逃すパターンです。書き換えられた部分は差分に出てくるのですが、書き換え忘れた部分は差分として出てこないからです。

とにかく私の周りでこのパターン多すぎてレビュー来るたびにげんなりします。どうすればよいのですか。教えてえらいひと。

第4位は以上です。その他のソフトウェアのテストを書くのが嫌になる瞬間は以下にまとめています。

yucatio.hatenablog.com

テスト駆動開発 [ Kent Beck ] 価格：3024円（税込、送料無料) (2018/12/28時点) 楽天で購入

ソフトウェアのテストを書くのが嫌になる瞬間 第3位

ソフトウェアのテストを書くのが嫌になる瞬間、今回は第3位です。

テストを書くのが嫌になる瞬間 第3位 : コードもテストも間違っているのをみたとき

今回は7コマ漫画2本でお送りします。

なお、以下単に”テスト”と書いた場合は、テストコードのことを指し、CIツールなどで自動実行されるものを指します。また、単に"コード"と書いた場合には、プロダクションコードを指します。 また、単体テストよりもエンドtoエンドのテストを厚く書く職場で働いています。

ケース1

あると思います。

人間だからミスはします。レビューに出す時点でバグがないことを求めてもしょうがないです。 ただ、直す手間が2重にかかることを考えると悲しい気持ちになります。

ケース2

ないと思います。実際にあった話ですが(コード間違っていて項目Fが出力されていなかった)。

テストケース作成の理想と現実

理想としては、テストもコードも仕様から作成するのが望ましいのです。

しかし、しばしばコードからテストケースの期待値を作成する例が見られます。

1人の人間がコードとテストを作成すると、仕様を勘違いしたままコードとテストを作成してしまうケースが発生しやすいです。コードを書いた後にテストを書くなら、もう一度新たな気持ちで仕様を読んでほしいですが、それが難しいことは想像に難くないです。

ところでTDDはこうだと思うのですが、

仕様からテストを作成する時に仕様を勘違いしてしまったらその勘違いに気づくのは結構後のフェーズだと思うのですがどうしているのでしょうか。

TDDは個人開発(仕様を作る人とテスト書く人が同一人物)か、ビジネスの仕様に左右されない部分(共通で使用される関数など)をテストする時に有用だとは思いますが、仕様を作る人とテストを書く人が別の場合、バグを防ぐという目的の達成はあまり期待しないほうがよい気がします。TDDを職場でやったことがないので想像ですが。

第3位は以上です。その他のソフトウェアのテストを書くのが嫌になる瞬間は以下にまとめています。

yucatio.hatenablog.com

テスト駆動開発 [ Kent Beck ] 価格：3024円（税込、送料無料) (2018/12/26時点) 楽天で購入

ソフトウェアのテストを書くのが嫌になる瞬間 第2位

前回に引き続き今回は第2位です。前回の記事はこちら↓

yucatio.hatenablog.com

テストを書くのが嫌になる瞬間 第2位 : 開発中に仕様が変わったとき

今回も11コマ漫画でお送りします。

なお、以下単に”テスト”と書いた場合は、テストコードのことを指し、CIツールなどで自動実行されるものを指します。 また、単に"コード"と書いた場合には、プロダクションコードを指します。 また、単体テストよりもイエンドtoエンドのテストを厚く書く職場で働いています。

あるあるではないでしょうか。実際にはもっとぐだぐだ説明してます。 (ちなみにCさんは仕様を決めたり他部署とのやりとりをしたりスケジュールを管理したりする役割の人です。)

コードの変更が数行でもテストの変更や追加が大幅になることがあります。特に1つのvalidationをするためのパラメータが3つや4つになってくると、単純に組み合わせぶんのテストをすると膨大な数になります。通常、全ての組み合わせぶんのテストをする必要はないので、どの組み合わせをテストするのか考えますが、これには時間が必要です。できているぶんのテストに追加しようと頑張りますが、大抵は1から作り直した方が早かったりします。 (ちなみに、すでに書いたテストを生かそうとして、テスト落ちたら期待値を書き換えるという手法をとると、期待値を検証せずに書き換えてミスに気づかないことが多いので絶対にやめとけ。)

ソースコードの変更が少ないので、プログラムを書く人以外にはテストの変更も少しであると思われるようです。毎回どうやったら分かってもらえるか苦心しています。

このように途中で仕様が追加されるのはプロジェクトの開始時にある程度予告されている(仕様が変わるかもと言われている)ことがほとんどですが、変わらないこともあるので進められるところまで進めてしまわなければなりません。

仕様が固まってから動きたいところですが、いろいろな部署が関わっている以上動かせるところは動かしてしまった方が良かったりするんですよね。理想的にはいかないものです。

こういうことが起こるので、TDDなどのテストを先に(または同時に)書く、という手法には、会社での開発には手が出しにくいと感じています。(個人での開発や少人数での開発には向くかもしれませんが)

第2位は以上です。ソフトウェアのテストを書くのが嫌になる瞬間は以下にまとめています。

yucatio.hatenablog.com

テスト駆動開発 [ Kent Beck ] 価格：3024円（税込、送料無料) (2018/12/22時点) 楽天で購入

ソフトウェアのテストを書くのが嫌になる瞬間 第1位

昔々、上級エンジニアのNさんは私に言いました。yucatioさん、テストはちゃんと書きましょう、と。 時は流れ、チームにテストを書く習慣ができました。めでたしめでたし。テストを書けば変更の影響がすぐに分かるので安全にリファクタリングができます。

でもなぜでしょう、たまにもうテスト書くのは嫌だという気持ちに襲われるのは。 そこでそんな気持ちになる瞬間をランキング形式にしました。

なお、以下単に”テスト”と書いた場合は、テストコードのことを指し、CIツールなどで自動実行されるものを指します。 また、単体テストよりもエンドtoエンドのテストを厚く書く職場で働いています。

テストを書くのが嫌になる瞬間 第1位 : テストを通すために期待値が上書きされたとき

ちょっとタイトルがわかりにくいので、10コマ漫画でお送りします。

(実体験を基にしています。)

これには参りました。テストを書く目的の1つとして、デグレを防ぐというものがありますが、完全に無効化されました。テスト書くのは面倒だし時間もかかります。それでもテストを書くのは、将来的にコードが変更されても動作が変わらないことを保証するためです。しかし、期待値を実行した結果で書き換えられてしまっては保証も何もありません(泣)。

この時は元のテストコードを書いた人(Aさん)がレビューしたから気づいたものの、Aさんがいなかったらきっとそのままマージされていたことでしょう。テストコードはプロダクションコードよりも読むのが面倒なことが多いので、注意して見ててても見逃してしまうことがあるので。

分かってはいます、Bさんのような人はごく一部だということは。しかし一度でもこのようなことをされるとテストを書いている最中、”テストを書いていてもどうせ間違った結果で上書きされるのではないか”、”それならテストを書かない方が良いのではないか”という極端な思考になってしまいます。もうトラウマですね。

おわりに

上級エンジニアの人たちは、テスト書け書けいう前に、自分が書いたテストが、間違った値で書き換えられている経験をしてほしいです。

現場からは以上です！

注) だからといっってテストを書かないという選択肢は自分にはないです！

2位以下は以下のカテゴリページからどうぞ。

yucatio.hatenablog.com

エンジニアの知的生産術 効率的に学び、整理し、アウトプットする （WEB＋DB　PRESS　plusシリーズ） [ 西尾泰和 ] 価格：2678円（税込、送料無料) (2018/12/20時点) 楽天で購入

Firebaseアプリの公開(STEP 4 : Material-UIの導入 - React + Redux + Firebase チュートリアル)

★前回の記事

yucatio.hatenablog.com

アプリの修正が完了したので、Firebaseにアプリを公開します。

ビルドします。

$ yarn run build

一旦ローカルで正常に動くか確認しましょう。

$ firebase serve --only hosting

http://localhost:5000にアクセスして、動作確認しましょう。 確認が終わったら、Firebaseにデプロイします。

$ firebase deploy --only hosting

=== Deploying to 'todo-sample-xxxxx’…

i  deploying hosting
i  hosting[todo-sample-xxxxx]: beginning deploy...
i  hosting[todo-sample-xxxxx]: found 8 files in build
✔  hosting[todo-sample-xxxxx]: file upload complete
i  hosting[todo-sample-xxxxx]: finalizing version...
✔  hosting[todo-sample-xxxxx]: version finalized
i  hosting[todo-sample-xxxxx]: releasing new version...
✔  hosting[todo-sample-xxxxx]: release complete
✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/todo-sample-xxxxx/overview
Hosting URL: https://todo-sample-xxxxx.firebaseapp.com

無事デプロイできたので、https://todo-sample-xxxxx.firebaseapp.com にアクセスします。(todo-sample-xxxxは自身のプロジェクトIDに置き換えてください。)

最近の更新

ログインしたユーザ自身のタスク一覧

ログインしたユーザ以外のタスク一覧

アプリが公開できました！ Material-UIのスタイルが適用されています。

これでSTEP 4は終了です。見た目が整うと誰かに見せたくなりますね。

★目次

yucatio.hatenablog.com

ロゴの作成と表示(STEP 4 : Material-UIの導入 - React + Redux + Firebase チュートリアル)

★前回の記事

yucatio.hatenablog.com

仕上げにロゴを作成して表示してみましょう。ロゴを、自動でかつ無料で作成してくれる便利なサイトがたくさんあります！

peraichi.com

今回はLOGASTERというサービスを使用します。

www.777logos.com

ロゴ作成の前にサービス名を決めます。今回はタスク管理アプリ(TODOアプリ)ということで、TODODO(トドド)というサービス名にしました。

サービス名の入力

ビジネスタイプを選択して次へ。

ロゴの候補がたくさん表示されます。

ロゴデザインの選択画面

今回はチェックマークっぽいロゴにしました。 ロゴの編集でフォントの種類やエンブレムの色を変えることができます。

ロゴの編集

無料では透かしが入っている小サイズのロゴをダウンロードできます。

ロゴのダウンロード

ダウンロードしたファイルを解凍すると6種類のロゴファイルが入っています。

ロゴをwebページに表示してみましょう。

1_Primary_logo_on_transparent_404x63.pngを src/img/logo/Primary_logo_on_transparent_404x63.png に配置します。ファイルをリネームしています。

src/components/header/index.js

import logo from '../../img/logo/Primary_logo_on_transparent_404x63.png'  // 追加
// import Typography from '@material-ui/core/Typography'  を削除

const Header = ({ classes }) => (
  <AppBar className={classes.appBar}>
    <Toolbar>
      {/* Typography を削除
        <Typography variant="h6" color="inherit" component={Link} to="/">
          タスク管理アプリ
        </Typography>
      */}
      {/* 追加ここから */}
      <Link to='/'>
        <img src={logo} alt="TODODO(トドド)" height="36" width="auto"/>
      </Link>
      {/* 追加ここまで */}
      <div className={classes.grow}></div>
      <MenuIcons />
      <Login />
    </Toolbar>
  </AppBar>
)

ページタイトルを書き換えます。

public/index.html

<html lang="en">
  <head>
    <!— 中略 —>
    <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,400,500" />
    <title>TODODO(トドド) タスク管理アプリ</title>  <!— 変更 —>
  </head>
  <!— 以下略 —>

実行結果です。ロゴが表示されました。

以上でロゴの作成と表示ができました。

★次回の記事

yucatio.hatenablog.com

★目次

yucatio.hatenablog.com

Material-UIのテーマカラーを変更する(STEP 4 : Material-UIの導入 - React + Redux + Firebase チュートリアル)

★前回の記事

yucatio.hatenablog.com

現在はデフォルトのテーマカラーを使用していますが、これを自分の好きな色に変えます。

今回はマテリアルデザインのカラーツールを使用します。

primaryとsecondaryの色を選択します。選択すると左側の画面にすぐに反映されるので、適用イメージを確かめならが選べます。 選択した色のカラーコードが右下に表示されます。

カスタマイズしたテーマ用のファイルを作成します。

src/materialui/theme.js(新規作成)

import {createMuiTheme} from '@material-ui/core/styles'
        
export const theme = createMuiTheme({  // #1
  palette: {
    primary: {
      light: '#ffff8b',
      main: '#ffee58',
      dark: '#c9bc1f',
      contrastText: '#000000',
    },
    secondary: {
      light: '#63a4ff',
      main: '#1976d2',
      dark: '#004ba0',
      contrastText: '#ffffff',
    },
  },
})

• createMuiThemeにテーマカラーを渡すことでデフォルトの設定を上書きしています(#1)。

作成したテーマをコンポーネントに渡します。<App>を<MuiThemeProvider>で囲うことでカスタマイズしたテーマを使用することができます。

src/index.js

import {MuiThemeProvider} from '@material-ui/core/styles'  // 追加
import {theme} from './materialui/theme'  // 追加

// 略

render (
  <Provider store={store}>
    <MuiThemeProvider theme={theme}>  {/* 追加 */}
      <App />
    </MuiThemeProvider>  {/* 追加 */}
  </Provider>,
  document.getElementById('root')
)

実行結果です。Appbarとボタンの色が変わりました。

以上でMaterial-UIのテーマカラーを変更できました。

参考

• Color - Material-UI
• Theming - Material-UI
• Material-UIでprimaryとsecondaryの色を変更する - Javaエンジニア、React+Redux+Firebaseでアプリを作る

★次回の記事

yucatio.hatenablog.com

★目次

yucatio.hatenablog.com