テスト仕様書の書き方とフォーマットが分からない人のためにテンプレートを作成しました

テスト仕様書を書いてくれと言われてもそのフォーマットは多種多様なものがあります。IPAなどの機関がフォーマットを定義していることもないため、新卒の新人でも渡されたテスト仕様書のフォーマットを見て「こんなフォーマットで良いのか…？」と戸惑う人もいるのではないでしょうか（実際僕がそうでした）。今回は試行錯誤して独自にテスト仕様書のフォーマットを固めてきたので、テスト仕様書の書き方とフォーマットについて公開したいと思います。

テスト仕様書とは

テスト内容によってフォーマットや書き方は多種多様

国内のテスト仕様書の多くはExcelで書かれているのではないかと思います（Googleスプレッドシートを含めて）。そのExcelファイルでもテストの内容によって書き方は変わってきます。

• 単体テスト
• シナリオテスト
• 回帰テスト（レグレッションテスト）

今回はシナリオテストに焦点を当てます。ちなみに単体テストはユニットテストとして開発者（プログラマー）が自動化して品質を担保している必要があるもので、本来は仕様書は不要なはずです。回帰テストも回帰テストの仕様書があるケースや、今まで発生した不具合を再度チェックするなど会社や組織によってやり方は様々でフォーマットや下記型定義は難しいです。

Swiftで一部の画面の回転禁止を導入したらiOS9はsupportedInterfaceOrientations was invoked recursivelyと例外が飛んでクラッシュする

iOSアプリ開発で、デザインの問題で一部の画面だけ回転を禁止にする必要が生じました。この一部の画面だけ回転を禁止するというのはUX的に問題があるのはそうなのですが、同時にAppleとしても推奨していないことのような気がします。案の定、iOS9でクラッシュするという不具合を作ってしまったので、今回はその原因と対策についてまとめます。

一部の画面だけ回転禁止にする方法

shouldAutorotateとsupportedInterfaceOrientationsをoverrideする

画面回転時に呼ばれるshouldAutorotateとsupportedInterfaceOrientationsをオーバーライドして回転をキャンセルすることができます。
qiita.com
qiita.com

VirtualBoxのUbuntu(ゲストOS)で起動したRails ServerにWindows(ホストOS)やLAN内のスマホでアクセスする方法

VirtualBoxのUbuntu上でRuby on Rails開発環境を構築したのは良いのですが、Rails ServerにホストOSのWindowsやスマホからアクセスするのに苦戦してしまったので忘れないうちにメモ書きしておきます。

VirtualBoxのネットワーク設定を変更する

ネットワークアダプターのポートフォワーディングを追加する

VirtualBoxのネットワーク設定を開きます。

ポートフォワーディングをクリックします。

ホストポートを適当な数字にします。

Windows10にVirtualBoxでUbuntuをインストールしてRuby on Rails開発環境を構築しました

Windows10にRuby on Rails開発環境を自宅に構築したので忘れないうちにメモ書きしておきます。

Ruby on Rails開発環境を構築する環境選び

Windows上に構築するのはやめた

最初はWindows上に構築しようと思ったのですが、もともとWindowsアプリ開発環境を整えているのでカオスになるのが嫌だなと思ってやめました。また、調べてみるとインストールが必要なものが多くて、それだけでOSを初期化したい衝動が後々に出てきても嫌だなと思ったのもあります。他にも、

• Windows上の開発について情報が少ない
• Windows向けのRubyのインストーラー開発が滞っている

などネガティブな情報が多くて個人的にもあまりオススメしません。

C#でcsharp2nemを使ってXEMやモザイクを任意のウォレットへ送金する

先日はcsharp2nemを使ってNEMのウォレットの情報を取得する方法について書きました。
www.k-karakuri.com
今回はcsharp2nemを使ってXEMやモザイクを送信する方法について書きます。

csharp2nemを使って送金の準備をする

接続するネットワークを選択する

前回同様、接続先をテストネットかメインネットか指定します。

var connection = new Connection();
connection.SetTestnet();

本番のメインネットの場合はこちら。

var connection = new Connection();
connection.SetMainnet();

XcodeのFrameworkでBridging Headerは使えないのでmodule.modulemapを追加してエラー回避する

外部ライブラリをラップするライブラリを作成して社内で使いまわすということをWindowsやAndroidでは当然のようにやってきたのですが、iOSでは簡単にできない場合があります。それはObjective-Cで書かれたライブラリをSwiftのFrameworkでラップする場合です。

FrameworkでObjective-CのFrameworkの組み込み時にエラー

error: using bridging headers with framework targets is unsupported

プロジェクトにObjective-Cで書かれたFrameworkを組み込む場合、Bridging Headerを追加して参照できるようにします。Frameworkで同じようにするとエラーが発生してビルドできません。エラーメッセージそのままですが、FrameworkではBridging Headerが使えないようです。

ググってもObjective-CのFrameworkを修正する方法ばかり

ではどうやって組み込むのかどうか、ググって調べてもObjective-CのFrameworkを修正してビルドし直すという方法ぐらいしか見つかりませんでした。しかし、今回のFrameworkはサードパーティー製でソースコードは手元になく修正はできません。

C#でcsharp2nemを使ってNEMのウォレットの残高などの情報を取得する

NEMはRESTFulな思想で開発が容易という特徴がありますが、さらに各言語にライブラリが公開されているので、NEMのブロックチェーンから情報を取得するのが容易になっています。今回はC#向けのライブラリであるcsharp2nemを使ってNEMのウォレットの情報取得を行ってみました。

NEMのC#向けライブラリcsharp2nemとは

Githubで公開されています

有志によって開発されGithubで公開されています。
github.com

Nugetでも公開されています

Nugetで公開されているので、Windowsアプリケーションとして利用する場合はこちらからインストールすると簡単にプロジェクトに導入できます。
www.nuget.org

Unityで使用することも可能

C#向けなのでUnityで利用することができます。つまり、AndroidやiOS向けに利用することも可能ということです。

C#のTaskを使った非同期処理のタイムアウトの実装方法について

データ量に比例して処理時間が増えるコードを非同期処理で実行していたのですが、データ量が少ないとプログレスリングがすぐ消えて画面のチラつきになってしまうことがありました。このため、処理時間が一定以上の場合はプログレスリングを表示し、一定未満の場合は表示しないというコードを書く必要があります。今回はその処理を実装するためTaskのタイムアウトを使用しました。

プログレスリングを毎回表示する場合

まずは基本的な非同期処理の実装についてです。時間のかかる重い処理をTask.Runで実行することで別スレッドで実行します。Thread.Sleepが実行されている間はUIスレッドは空いているので、UIがフリーズすることはありません。

async void Method()
{
     ProgressRing.Visibility = Visibility.Visible;
     await Task.Run(() => Thread.Sleep(10000));
     ProgressRing.Visibility = Visibility.Hidden;
}

このケースはこれで問題ないのですが、Thread.Sleepの時間が動的に変わる場合はどうでしょうか？

async void Method(int time)
{
     ProgressRing.Visibility = Visibility.Visible;
     await Task.Run(() => Thread.Sleep(time));
     ProgressRing.Visibility = Visibility.Hidden;
}

多くの場合が100とか200とかだとプログレスリングのチラつきを指摘される可能性があります。このケースだとシンプルなのでtimeの値によってプログレスリングの表示を制御できますが、当然ながら実行してみなければ時間が分からないケースのほうが多いでしょう。

SwiftとiOSで定期的なバックグラウンド処理の実行は不可能なので諦めるべき

AndroidやWindowsではバックグラウンドで定期処理を実行することは比較的容易です。これと同様にiOSでも同じ機能を実装しようとすると問題に直面します。直面するというか、その機能はiOSでは実装できません。

iOSのバックグラウンド処理

UILocalNotificationで実行

UILocalNotificationを使えば、指定時間後にiOSからアプリの処理を実行させることができます。アプリがバックグランドでも、起動していなくても可能です。しかし、これはNotificationの通知からアプリを起動したときに呼ばれるメソッドです。Notificationの通知が発生したら呼び出されるわけではありません。起動中だと呼び出されるのですが。バックグラウンドで継続して定期的な処理を走らせることはできません。なお、iOS10以降ではUILocalNotificationはdeprecatedとなっており、UNNotificationRequestを使うように勧告されています。

レガシーコードの特徴を具体的な4つの例を示して問題点をまとめます

新卒で入社した企業では20年物のソースコードが現役で動いていたりしました。しかも協力会社に丸投げした部分やインドにオフショアした部分などが入り混じってカオスとなっていました。エンジニアも玉石混在で、カオスに練度の低いエンジニアが保守拡張したりしてカオスがさらにカオスに。そんなソースコードには発狂しそうになるレガシーコード（一部ではウンコードと呼ぶ人もいる）が豊富に眠っていました。今回はレガシーコードの反面教師としてその具体例を挙げてみます。

レガシーコードの具体例

意図が分からない

if ( path != null )
{
    str = Path.Combine(path, fileName);
}
else
{
    str = path + fileName;
}

たぶんpathがnullでPath.Combineでクラッシュする不具合があったんでしょうね。それを修正した結果が上のコードになったのでしょう。pathがnullのときクラッシュすることはこれで回避できた（できてるこれ？）かもしれませんが、nullのときstrは本当に問題ないんですかね…。この不具合修正で新たな不具合を作っていそうです。