yucatio@システムエンジニア

趣味で作ったものいろいろ

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

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

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

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

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

ケース1

f:id:yucatio:20181226144733p:plain:w300

f:id:yucatio:20181226144750p:plain:w300

あると思います。

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

ケース2

f:id:yucatio:20181226145525p:plain:w300

f:id:yucatio:20181226145537p:plain:w300

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

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

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

f:id:yucatio:20181227085748p:plain:w350

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

f:id:yucatio:20181227085710p:plain:w350

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

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

f:id:yucatio:20181227085725p:plain:w350

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

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

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

yucatio.hatenablog.com

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

テスト駆動開発 [ Kent Beck ]
価格:3024円(税込、送料無料) (2018/12/26時点)


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

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

yucatio.hatenablog.com

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

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

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

f:id:yucatio:20181222230305p:plain:w300

f:id:yucatio:20181228162835p:plain:w300

f:id:yucatio:20181222230336p:plain:w300

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

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

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

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

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

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

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

yucatio.hatenablog.com

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

テスト駆動開発 [ Kent Beck ]
価格:3024円(税込、送料無料) (2018/12/22時点)


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

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

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

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

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

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

f:id:yucatio:20181220125009p:plain:w300

f:id:yucatio:20181220124821p:plain:w300

f:id:yucatio:20181220124835p:plain:w380

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

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

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

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

おわりに

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

現場からは以上です!

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

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

yucatio.hatenablog.com


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に置き換えてください。)

f:id:yucatio:20181219103049p:plain
最近の更新

f:id:yucatio:20181219103107p:plain
ログインしたユーザ自身のタスク一覧

f:id:yucatio:20181219103136p:plain
ログインしたユーザ以外のタスク一覧

アプリが公開できました! 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(トドド)というサービス名にしました。

f:id:yucatio:20181216212619p:plain
サービス名の入力

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

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

f:id:yucatio:20181216212652p:plain
ロゴデザインの選択画面

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

f:id:yucatio:20181216212754p:plain
ロゴの編集

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

f:id:yucatio:20181216212907p:plain
ロゴのダウンロード

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

f:id:yucatio:20181216213356p:plain

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

1_Primary_logo_on_transparent_404x63.pngsrc/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>
  <!— 以下略 —>

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

f:id:yucatio:20181216214537p:plain

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

★次回の記事

yucatio.hatenablog.com

★目次

yucatio.hatenablog.com

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

★前回の記事

yucatio.hatenablog.com

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

f:id:yucatio:20181216135813p:plain

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

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

f:id:yucatio:20181122231844p:plain

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

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とボタンの色が変わりました。

f:id:yucatio:20181216135836p:plain

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

参考

★次回の記事

yucatio.hatenablog.com

★目次

yucatio.hatenablog.com

タスクの送信状態の表示(STEP 4 : Material-UIの導入 - React + Redux + Firebase チュートリアル)

★前回の記事

yucatio.hatenablog.com

タスクの送信状態を表示するように変更します。タスクの各行に送信状態を表すアイコンを表示します。

今回のタスク管理アプリの場合、送信状態を表示することは必須ではありませんが、 チャットアプリのような相手がいて即時性が求められるアプリの場合は、サーバへの送信状況を表示した方がよいでしょう。

f:id:yucatio:20181215222506p:plain

方針

タスクの送信状態を、各タスクの横にアイコンを表示することで示します。

  • サーバにデータを送信中は送信中のマークをタスクの横に表示します。今回は右上向きの矢印を表示します。
  • サーバへのデータ送信が終了後、アイコンを消します。
  • エラーが発生した場合はエクスクラメーションマークのアイコンを表示します。

stateオブジェクトの設計

各タスクの状態を持つtodoStatusesオブジェクトを用意します。todoStatusesの各プロパティはキーをtodoIdにすればよさそうです。以下の"aaabbbcccxxxfff""cccdddeeefff""gggeeefffttt"はtodoIdです。

state = {
  todoStatuses : {
      "aaabbbcccxxxfff" : {
        status : “sending},
     "cccdddeeefff" : {
        status : “success},
     "gggeeefffttt" : {
        status : “error}
  }
}

新規登録時のtodoIdの事前取得

上記のデータ構造を採用する際、 タスクの更新時にはすでにtodoIdが分かっているのでtodoIdをキーとすることは可能です。しかし新規登録では、現在の実装ではtodoIdが分かるのはタスクの登録後です。それでは送信中のステータスを表示することができません。

そこで、新規タスクを登録する前にtodoIdを取得するようにコードを変更します。また、reducerにtodoIdを渡すようにも変更します。

src/actions/todoActions.js

const addTodoRequest = (todoId) => ({  // todoIdを追加
  type: ADD_TODO_REQUEST,
  todoId,  // 追加
})

const addTodoSuccess = (todoId) => ({  // todoIdを追加
  type: ADD_TODO_SUCCESS,
  todoId,  // 追加
})

const addTodoError = (todoId, err) => ({  // todoIdを追加
  type: ADD_TODO_ERROR,
  todoId,  // 追加
  err,
})

export const addTodo = (uid, text) => {
  return (dispatch, getState, {getFirebase}) => {
    if (!uid) {
      dispatch(notAuthenticatedOnTodoAction());
      return;
    }
    // dispatch(addTodoRequest()); は下に移動
    const firebase = getFirebase();
    const id = firebase.push(`todos/${uid}`).key;  // #1
    dispatch(addTodoRequest(id));  // idを引数に追加
    const createdAt = moment().valueOf();
    firebase.set(`todos/${uid}/${id}`,{  // #2
      completed: false,
      text,
      _createdAt : createdAt,
      _updatedAt : createdAt
    })
    .then(() => {
      dispatch(addTodoSuccess(id));  // idを引数に追加
    }).catch(err => {
      dispatch(addTodoError(id, err));  // idを引数に追加
    });
  }
}
  • firebase.push(`todos/${uid}`).keyで新しいデータのkey(id)を取得することができます(#1)。この操作はサーバ通信を行わないため、すぐに結果が返ってきます。
  • 上で取得したidを使ってtodos/${uid}/${id}にデータをセットします(#2)。pushからsetに変更してあることに注意してくだい。

更新時にtodoIdをactionに渡す

更新時、現在の実装ではタスク名と完了グラグを渡していますが、todoIdを渡すように変更します。

src/actions/todoActions.js

const toggleTodoRequest = (todoId) => ({  // text, completedを削除し、todoIdを追加
  type: TOGGLE_TODO_REQUEST,
  // text, を削除
  // completed を削除
  todoId,
})

const toggleTodoSuccess = (todoId) => ({  // text, completedを削除し、todoIdを追加
  type: TOGGLE_TODO_SUCCESS,
  // text, を削除
  // completed を削除
  todoId,
})

const toggleTodoError = (todoId, err) => ({  // text, completedを削除し、todoIdを追加
  type: TOGGLE_TODO_ERROR,
  // text, を削除
  // completed, を削除
  todoId,
  err,
})

export const toggleTodo = (uid, id) => {
  return (dispatch, getState, {getFirebase}) => {
    if (!uid) {
      dispatch(notAuthenticatedOnTodoAction());
      return;
    }
    const firebase = getFirebase();
    const state = getState();
    const todo = state.firebase.data.todos[uid][id];
    dispatch(toggleTodoRequest(id));  // todo.text, !todo.completedを削除し、idを追加
    const updatedAt = moment().valueOf();
    firebase.update(`todos/${uid}/${id}`, {
      completed: ! todo.completed,
      _updatedAt : updatedAt
    })
    .then(() => {
      dispatch(toggleTodoSuccess(id));  // todo.text, !todo.completedを削除し、idを追加
    }).catch(err => {
      dispatch(toggleTodoError(id, err));  // todo.text, !todo.completedを削除し、idを追加
    });
  }
}

reducerの実装

actionを受け取った時に、todoIdごとにステータスを設定します。

src/reducers/todoStatuses.js(新規作成)

import { LOCATION_CHANGE_ON_TODOS, LOGOUT_SUCCESS,
  ADD_TODO_REQUEST, ADD_TODO_SUCCESS, ADD_TODO_ERROR,
  TOGGLE_TODO_REQUEST, TOGGLE_TODO_SUCCESS, TOGGLE_TODO_ERROR,
   }
   from '../actions/'

const INITIAL_STATE = {}

const todoStatuses = (state = INITIAL_STATE, action) => {
  switch (action.type) {
    case ADD_TODO_REQUEST:
      return { ...state, [action.todoId]: {status : 'sending'}}  // #1
    case ADD_TODO_SUCCESS:
      return { ...state, [action.todoId]: {status : 'success'}}
    case ADD_TODO_ERROR:
      return { ...state, [action.todoId]: {status : 'error'}}
    case TOGGLE_TODO_REQUEST:
      return { ...state, [action.todoId]: {status : 'sending'}}
    case TOGGLE_TODO_SUCCESS:
      return { ...state, [action.todoId]: {status : 'success'}}
    case TOGGLE_TODO_ERROR :
      return { ...state, [action.todoId]: {status : 'error'}}
    case LOCATION_CHANGE_ON_TODOS:
    case LOGOUT_SUCCESS :
      return INITIAL_STATE
    default:
      return state
  }
}

export default todoStatuses
  • stateに、todoIdをキーとしstatusプロパティを持ったオブジェクトを追加(または上書き)します(#1)。[action.todoId]action.todoIdが表す値がキーになります。

src/reducers/index.js

import todoStatuses from './todoStatuses'  // 追加

export default combineReducers({
  firebase: firebaseReducer,
  auth,
  notice,
  todoStatuses,  // 追加
  visibilityFilter
})

送信ステータスの表示

送信ステータスを表示します。

todoStatusをstateから読み込みます。

src/containers/todos/VisibleTodoList.js

const mapStateToProps = ({todoStatuses, visibilityFilter, firebase: {auth, data : {todos, users}}}, {uid}) => { // todoStatusesの追加
  return {
    todos: getVisibleTodos(todos && todos[uid], visibilityFilter),
    todoStatuses,  // 追加
  }
}

todoStatuses[key]を各todoに渡します。

src/components/todos/TodoList.js

const TodoList = ({todos, isOwnTodos, todoStatuses, onTodoClick, classes}) => {  // todoStatusesを追加
  // 略
  return (
    <List>
      {Object.keys(todos).map(
        (key) => (
          <Todo
            key={key}
            isOwnTodos={isOwnTodos}
            {...todos[key]}
            todoStatus={todoStatuses[key]}  // 追加
            onClick={isOwnTodos ? (() => onTodoClick(key)) : (() => {})} />
        )
      )}
    </List>
  )
}

TodoList.propTypes = {
  // 略
  todoStatuses: PropTypes.object.isRequired,  // 追加
}

送信ステータスによってアイコンを出し分けます。

src/components/todos/Todo.js

import Tooltip from '@material-ui/core/Tooltip'  // 追加
import CallMade from '@material-ui/icons/CallMade'  // 追加
import Error from '@material-ui/icons/Error'  // 追加

// StatusIcon関数の追加
const StatusIcon = (todoStatus) => {
  if (!todoStatus) {
    return null;
  }

  if (todoStatus.status === 'sending') {
    return (
      <Tooltip title="送信中">
        <CallMade />
      </Tooltip>
    )
  }
  if (todoStatus.status === 'error') {
    return (
      <Tooltip title="エラー">
        <Error />
      </Tooltip>
    )
  }
  return null
}

const Todo = ({isOwnTodos, onClick, completed, text, todoStatus}) => (  // todoStatusの追加
  <ListItem
    button={isOwnTodos}
    onClick={onClick}
  >
    {CheckIcon(isOwnTodos, completed)}
    <ListItemText inset>
      <span style={ {textDecoration: completed ? 'line-through' : 'none'}}>{text}</span>
    </ListItemText>
    {StatusIcon(todoStatus)}  {/* 追加 */}
   </ListItem>
)

Todo.propTypes = {
  // 略
  todoStatus: PropTypes.shape({  // 追加
    status: PropTypes.oneOf(['sending', 'success', 'error']).isRequired
  })
}

実行結果

実行結果です。

送信中は右上向きの矢印とマウスオーバー時に送信中のツールチッブが表示されます。

f:id:yucatio:20181215222506p:plain

エラー時はエクスクラメーションマークとマウスオーバー時にエラーのツールチッブが表示されます。 (通常の操作ではエラーが発生しないので、少しソースを変更してエラーを出しています。)

f:id:yucatio:20181215222521p:plain

以上でタスクの送信状態を表示することができました。

参考

★次回の記事

yucatio.hatenablog.com

★目次

yucatio.hatenablog.com