動作確認のすゝめ

新人プログラマ応援キャンペーンという事で、私が普段気を付けている動作確認について網羅してみました。
ノリと勢いで書いてみたので、もし「この観点抜けているよ！」というのがあればコメントを頂ければと思います。
少しでも新人プログラマの皆様にお役に立てれば幸いです。

また前回の記事も好評だったのでよろしければご参考にして頂ければ幸いです！

初期値だけで満足しない

例えばWebアプリケーションでフロント⇔サーバーの疎通がうまくいった場合でも画面が正しく制御できてるか油断できません。
例えばこんな画面があったとします。

入力値の項目が複数あり、全ての値が入力されたらSubmitボタンを有効にする。この画面は新規登録/更新は同じHTMLを使うケース

新規登録画面の画面表示時の際は

• 入力項目は全て空文字
• Submitボタンはdisabledで表示する

というのが正しい挙動そうですね。
コードにするとこんな感じでしょうか。

  const name = document.getElementById('name');
  const message = document.getElementById('message');
  const button = document.getElementById('submit');

  const controlSubmitButton = () => {
    if (name.value === '' || message.value === ''){
      button.setAttribute('disabled', 'disabled');
    } else {
      button.removeAttribute('disabled');
    }
  }

  name.addEventListener('change', (e) => {
    controlSubmitButton();
  });

  message.addEventListener('change', (e) => {
    controlSubmitButton();
  });

HTMLのボタンの初期値にdisabledを入れれば問題なさそうですね。
ただし、これが更新画面があった場合はどうなるでしょうか？

• 入力項目は最終更新された値をそれぞれ表示する
• Submitボタンは値がすべてあった場合はenabled、それ以外はdisabledのケース

もし初期表示の際に値がどちらとも存在してた場合、disabledになってしまい正しく挙動が担保できなくなってしまいます。

その際は下記コードを入力しないと正しく動作しません。

window.addEventListener('load', () => {
  controlSubmitButton();
});

なので画面遷移のパターンがどうなるかをチェックしていく必要があるので、前提条件としてどういったものが存在するのかをチェックしていく必要があります。

初期値のパターンを変えてみる。

Webアプリケーションなどでダミーデータや単体テストなどを行う際に何らかの値を挿入する必要があるかと思います。
その際に注意して頂きたい点についてです。
（JavaScript(以下JS)だと説明が難しいというか特殊なので、C#で記述します）

public class Example 
{
  public string name {get; set;}
  public int seq {get; set;}
  public DateTime date {get; set;}
  public bool flag {get; set;}
}

言語によってはデフォルトの初期値が存在するので、そちらは避けた方がよろしいかと思います。

ダメな例

var example = new Examle()
{
  name = null,
  seq = 0,
  date = new DateTime(),
  flag = false,
};

この例はC#の初期値をそのまま挿入してしまっているので、DBやロジックなどで値が書き換わったかどうかの判定が完全にできていません。
ダミーデータの作成の際は極力使わない様にしましょう。

正しい例

var example = new Examle()
{
  name = "test", // 何らかの文字を挿入する。
  seq = 1, // 0を使用しない。
  date = new DateTime(2023, 4, 2), // 日付を挿入する。
  flag = true, //falseは使用しない。
};

勿論ケースバイケースにはよりますが、単体テストの値チェックは初期値を使わない方がベターです。
なお言語によって初期値が異なります。なので参画するプロジェクトの言語によって調査した方が精度の高いテストパターンを組むことができます。

文字列のパターンについて

文字列は一番検証する項目が多くて大変ですが、しっかりとチェックする際は以下のパターンもチェックした方が良さそうです。

文字列	目的	補足
(空文字))	空文字のチェックに使用	str !=== ''などのチェックで判定されるか
null	nullチェックに使用
記号全般	エスケープ処理が正しく実装されているか
環境依存文字	不正な値として検知するか or ただし8区反映されるか
絵文字	不正な値として検知するか or ただし8区反映されるか
';delete from table;	SQLインジェクション対策
半角カナ	正規表現が正しく動作しているか
超過文字オーバー	DBの桁数をオーバーする文字数を入力する	varchar(20)の場合は21文字分入力して、キチンとエラーが出るかを検証する
<script>alert('IS BUG) </script>	XSS対策	画面に表示する際にアラートが出ずに文字列として認識されるか

これらはあくまでの一般的な検証内容になるため、プロジェクトの共通の仕様書を確認しながら行うのが最適解となります。ですが考慮すべきポイントの視点は持っておくと良いかもしれません。

やってはいけない文字列挿入について

また挿入してはいけない文字列も存在します。システムの挙動というかモラル的に。。。

文字列	理由	補足
実在する会社名	クライアントや自社サービスに迷惑が掛かる	（これやるお客さん意外といます…ダミーデータを貰った際はPLに報告しましょう。）
個人情報	仮に消してもGitで残ります。	ソースコードは会社の成果物なので、不用意に個人情報を載せない方がよいでしょう。
差別用語	人格を疑われます。	人の気持ちが分かる大人になりましょう。
「う〇こ」「お〇ぱい」等	人類に勝てないものを書くべきではありません。あなたの人格が疑われます。	夢を見る島のどろぼーのように不名誉な称号が一生付きまといます。

パターンの網羅ができているか

この辺りの記事でも記載がある通り、全ての引数や条件の因子などを網羅しましょう。
前述した「新規登録」「編集」の挙動のパターンがある通り、動的な画面では1パターン以上が存在します。
テスト観点を正しく網羅できる能力は実装で必ず役に立ちます。

ザっと考えてみましたが、網羅すべきパターンはこんな感じでしょうか。
画面の場合のみで考えております。

• ログイン後なのか、そうじゃないのか
• 遷移前の画面からパラメータは渡ってくるのか
• リロードした場合
• ブラウザバックをした状態

他にもあると思いますが、画面によって違うのでその辺りは上長とコミュニケーションを取っていきましょう。

戻るボタンの制御について

HTMLの画面上に戻るボタンがあると思いますが、それはどういった挙動が正しいかは仕様書やコミュニケーションでしっかりと確認しましょう。

• ブラウザバックと同じ挙動？
• それとも再度POSTするの？

などなど。アプリがどうして動くのか？を視野を広げてみると観点が思いつきやすいですし、新人の皆様は先輩の助言を取り入れて、何故それが必要かを理解した上で進めていきましょう。

トグル系のコンポーネント

ON→OFF、OFF→ONなどの動作は未実装であるケースがごくまれに存在します。
見た目だけの場合はCSSで行うのが一番理想なのか、JSで組んでしまう場合はちゃんと網羅できているのか等が見落としやすいポイントとして挙げられます。

追加/削除が可能な動的リスト

TODOリストのようにカードを追加や削除の動作はJSのイベントの紐づけで上手くいかないケースがあります。

例えばこんな感じの画面があったとします。

• 追加ボタンを押下すると「項目～削除」の項目が追加されます
• 削除ボタンを押すと該当の列の項目が削除されます

こういった際に初期状態の追加/削除は正しく動作するけど、動的に追加された項目が動かないというケースが記述の仕方によって発生します。
結論からいうとイベントハンドラの紐づいてないというのが原因なんですが。

動作確認としては

• 追加を押下したものが正しくバリデーション/削除可能。ツールチップなどが動作する
• 削除後に追加ボタンを押して、動作が正しく動く
• 3件動的リストがあった場合、2件目を削除してIDやシーケンスなどに矛盾が存在しない

などです。

画面仕様を横展開で見てみる

新人さんは共通基盤やレイアウトを作るとかよりも、共通ではない機能単位の設計や実装が中心に担当されると思います。
その際は参考になる画面を1つの画面を見るというより、複数画面を見て共通化されている画面などを参考にしてみましょう。

• コンポーネント間の余白のサイズについて
• テキストサイズ等の意味合いについて
• メッセージの妥当性

これらの項目は1画面だけで判断するのは早計なので、複数の画面を見て共通仕様を把握しましょう。

マルチブラウザ、デバイスサイズについて

主要ブラウザとしてChrome、Safari、Edge、Firefoxなどがありますが、要件としてブラウザは何なのか、スマホ、タブレットのサイズ（閾値）は何なのか等を予め確認してもらうと出戻りや不具合が少ないです。

• 使用しないブラウザは何なのか？
  • 対応しているECMASCript等の確認をする為に必要です
• スマホ、タブレットのサイズの大きさを確認する
  • MediaQueryなどの判定に使用するので必要です
• ウインドウを狭めた際の挙動
  • 横スクロールが意図しない形で発生しないか
  • コンポーネントの位置や文字サイズが意図したものになるか

この辺りは正解があるようでないのが中心なので、「こうあるべき」に進めるのではなく、このアプリは「どうあるのが正解なのか」と観点を少し変えてみてみましょう。

ログやエラーについて

忘れがち、見落としがちですがこの辺りの挙動は大事です。

• エラーログを出力する項目やタイミングについて
• 不要なログは実装されていないか
• エラーが発生した場合のUI挙動はどうするか
  この辺りはテックリーダーやPLと整理して、運用側の考慮も検討しながら設計を進めていきましょう。

おわりに

ザっと書き殴ってみましたが、動作確認のすゝめです。
まだまだ書き足りないとは思ってますが、キリがないので一旦このくらいにしたいと思います。
また、弊社では採用や技術イベントを定期的に開催していく予定です！
この件だったり、この件以外の事でも何でもありましたらTwitterなどでお問い合わせ頂ければと思います！