E2Eテストをユーザーストーリーに沿って作成するというアイデアについて

E2Eテストをユーザーストーリーに沿って作成するというアイデアについて。

これは実際筋のいい考えかただと思うんだけど、あまりうまく適用できない部分がある。たとえば、これ

github.com/tai2/Voic…

ユーザーストーリー風に命名すると、As a user, I want to launch appみたいなタイトルになると思うんだけど、アプリを起動しただけでは、ユーザーになにも価値を提供していないので、これはユーザーストーリーとして、あまり適切ではないと思う。一方で、ホーム画面に表示されているアプリ名(画像だと「ボイスポスト」)が表示されていることも仕様の一部として確認したい。

しかし、この「アプリ名がホーム画面に表示されていること」という仕様をユーザーストーリーとして記述することに難しさを感じる。タイトルになにかが表示されているということそれだけでは、価値を含む機能として足りない感じがするので。まがりなりにもユーザーストーリーというからには、なにか価値を伴わなければならない。つまり、ユーザーストーリーという単位は、機能には含まれないけど、壊れていて欲しくはないというような、たとえばデザイン的な部分などをうまく扱えない気がする。

これについてどう処理するのがいいのかなと考えると、たぶん、理想的でないユーザーストーリーを妥協して受け入れるというのが、まあいいのかな、という気がしてる。いまのところ。

EASの設定ストレスフルが過ぎるな…一回の試行に時間がかかりすぎる………

https://github.com/byCedric/eas-gha

これ見て気付いたけど、eas build --local って、すくなくとも4年前から存在するんだな。そしていまだにexperimental扱い。正式公開はするつもりないってことかな。まあぶっちゃけローカルオプションがあればEASっていうCI/CDサービス自体いらない子になっちゃうしな。

さっきの記事の、AIにマルウェア検知させるっていうのけっこう有効そうだよな。パイプでAI挟んでシェルに渡す前に、AIに診断させてもいいかもしれない。

最近react-native使ってて思ったわりと本質的なこととして、まあメリット・デメリットあるなあと。共通コードで2プラットフォーム対応できるのは、もちろんめちゃくちゃうれしい。一方で、かなり分厚めの余分なレイヤーが挟まるので、バグを始め、余計な問題が持ち込まれる可能性は高まる。なんか問題あったときに、あれこれどのレイヤーの問題だ?っていうので、問題のスコープが広くなるのはデメリット。とはいえ、目玉の数の多さがけっこうカバーしてくれる面はあって、react-nativeのコミュニティーの厚さは感じた。問題を検知して修正していく作用がかなり働いてる点は好感触。

zenn.dev/mameta29/…

これは怖いーーー。おれも騙されそう。最近はリモートシェルコードをcurlでダウンロードして(中身見ずに)実行したりすることなどにも慣れてきってしまったしなあ。気をつけねば…。