軽量なStorybook駆動開発を支えるコンポーネント設計
こんにちは。この記事ではStorybook駆動開発をゼロから導入するために実践した内容をコンポーネント設計の側面から紹介します。合わせて、紹介した設計を元にどのようなテストを実装しているかについても紹介します。 簡単に実装できることが持続可能なテストへの鍵 Webフロントエンドの持続可能なテスト文化を醸成するためには、テストを開発フローの中で簡単に実装できることが何よりも重要です。テストの実装に機能開発以上のコストが掛かってしまう場合、「時間が無いのでテストコードを後から実装する（結果実装されない）」という典型的なアンチパターンに繋がってしまいます。 持続可能なテストを実現するためのアプローチ フロントエンドにおいて、特にIntegration Testの実装容易性は、コンポーネント設計やツールの使い方によって大きく左右されます。 筆者が関わるプロジェクトでは軽量なStorybook駆動開
キメる Clojure チーム開発 - Qiita
この記事は Clojure Advent Calendar 2019 18 日目の記事です。二年前に書いたキメるClojure高速開発が未だに読まれている気配があるので、情報を最新化し、現時点での意見をまとめようと思います。 当時の意見は特に Clojure 開発の高速性に注目し、短いスパンで進める個人開発に特に向いているというものでした。一方で経験にないため憶測でしたが、チームで進める中規模以上の開発にはあまり向かないのではないかと考えていました。しかし現在はチームとして Clojure を使って開発を行っているため今回はその観点から「Clojure を使ったチーム開発ってどうなの？」に対する意見を書きます。 私と Clojure のそれから 2014 年に上司の指導で Clojure に入門してから五年が経ちました。 2018 引き続きシリコンバレー駐在。 プロトタイプ開発などで許され
GraphQLを活用したスキーマ駆動開発を体験した話 - Qiita
概要 会社でGraphQLを導入するにあたり、スキーマ駆動開発を取りいれた開発を行ってみました。 実際にどのような開発を行ったのか、またやってみてどうだったかをご紹介できればと思います。 一度下記LTにて紹介した内容について少し加筆や修正を行った記事になります。 GraphQLにおけるスキーマ駆動開発 GraphQLを導入する利点の1つとして「スキーマ駆動」が実現できることがあります。 スキーマ駆動開発についてはこちらのqsonaさんの資料が詳しいです。 GraphQLを構築する方法として、コードファーストとスキーマファーストの２つのアプローチがあります。 コードファーストは、APIのスキーマをGraphQLのコードで定義してスキーマを生成する方法です。スキーマを定義するために、GraphQLの型を定義し、それらの型を組み合わせて、クエリを定義します。 スキーマファーストは、APIのスキー
Python製のシンプルなゲーム開発用ライブラリを作った - Qiita
崩壊しないシステマティックなゲーム開発がしたい ということで、Python 製のミニマルなゲーム開発用ライブラリ Pigframe を作りました。 主には、Pygame, Pyxel などの Python 製のゲーム開発エンジンを使ってゲームを開発したいと思っている、開発を始めた個人開発者・学習者向けになります。 依存している外部ライブラリはありません。 自分がゲーム開発で使っている/使いたい Pygame や Pyxel などの開発エンジンと併せて使うことを主な用途として想定しています。 さっさと使い方を見たい方はこちら: 日本語版 README ◼ 一体全体なにができるの？ Pigframe は以下のような仕様を持っています。 機能 対応 備考
playwrightとGitlab CI/CDでE2Eテストを自動化してみた - Qiita
この記事はニフクラ 等を提供している、富士通クラウドテクノロジーズ Advent Calendar 2022 の7日目の記事です。 前日は@heriet さんの trivy+conftestで柔軟にライセンスポリシーをチェックする でした。 ライセンスポリシーのチェックをより容易に、汎用的にできるというのは魅力的で私自身すごく勉強になりました。 はじめに 初めまして！ 私は富士通クラウドテクノロジーズ2年目の社員で、基幹システムの運用・開発をしております。 今回は実際に私が部署で管理しているWEBアプリのE2EテストをPlaywightとGitlab CI/CDで自動化した経験から、自動化までの簡単な流れを書こうと思います。 E2Eテストとは E2E（エンドツーエンド）テストは、User Interface Testとも呼ばれております。 WEBアプリにおいて、ユーザの想定される操作に対し
あなたはフロントエンドの何をテストしたいのか。 - Qiita
フロントエンドのテストをしよう Webのフロントエンドの自動化を進めようか。という話をしていて、 「そもそもテストってなんだ？」 「フロントエンドに特有のテストってなんだ？」 「〇〇ってツール流行ってるらしいってどうよ？」 みたいなことを話をしていました。そうしたときに、やっぱり知識足らねぇなぁ。と思ったので、2,3日でゴリゴリと内容をまとめてみる作業をしてみました。 あんまりこういう書き方はしないんですが、私自身散発的な思考で、フロントエンドのテストを調べることをしたので、そのような語り口で書いてみようと思います。 以下の内容は、あくまで例なので、別にこういう仕事があったわけではないです。 とりあえず投げられた要求・仕様 とりあえずなんか仕事が振ってきた。パラパラと要求を聞いてみると、こんな感じだった。 承認のダイアログが欲しい メッセージのフォントはOswald メッセージは変更できる
E2E テストの決定版！ テスト開発の効率が爆上がりする Playwright (TypeScript版) - Qiita
E2E テストの決定版！ テスト開発の効率が爆上がりする Playwright (TypeScript版)フロントエンドVisualStudioCodeE2EテストCypressPlaywright E2E テストスイート Playwright はマイクロソフトが提供しているだけあって Visual Studio Code と高いレベルで統合されています。 E2E テストをステップ実行することができ、変数の値を参照（インスペクト）できます。もちろん、ブラウザーの様子も同時に確認できます。 現在テストがどこを実行中なのかがテストコードにリアルアイムに強調表示されるので、どこで意図せずに止まっているかがすぐに分かります。この機能は追うのが難しい非同期処理にも対応しているので非常に助かります。 テストを動かさなくてもコードにマウスを合わせるだけで、対応する GUI 部品がどこにあるかがすぐに分か
OpenAPI Generatorを使ったスキーマ駆動開発でAPI仕様と型安全な実装を同時に得るための方法 - Qiita
本記事は CBcloud Advent Calendar 2020 の8日目の記事です。 TL;DR 書くこと：OpenAPI Generatorの紹介と実例 書かないこと： TypeScript + Axios以外の環境での実践方法 記事内で登場するライブラリの細かな紹介 モチベーション ドキュメントが無いことが只々ツラいからどうにかしたい WebAPIの戻り値をフロント側で愚直に型定義するのをやめたい バックエンド・フロントそれぞれの都合だけでAPIの仕様を決めない未来を作りたい ドメインモデルを検討する上では双方歩み寄れる筈 OpenAPI Gereratorとは？ そもそものOpenAPIは何かというと、OpenAPI SpecificationというREST APIのドキュメントなどを記述する形式のことを指します。 宣言的なDSLを使ってAPIのスキーマを定義できます。 で、Op
Stoplight + GitHub/CircleCI + Slack で OpenAPI Documentation 管理 - Qiita
Stoplight + GitHub/CircleCI + Slack で OpenAPI Documentation 管理CircleCIOpenAPImoxci First OpenAPI で仕様書いてて，GitHub に Push したら，CD 的なことしたいなーSlack に投げてほしいなーと思うじゃないすか． 今回はその方法について試したのでざっくり書いていきます． 雑な図を描くとこんな感じです． 実際の sample も置いておきます． Slack 連携については，ほぼ moxci の紹介です．便利やったんや・・ Local 環境の構築， Stoplight Studio の導入や CircleCI の導入には今回は触れません． Stoplight によるサンプル API の作成 Stoplight でははじめやすいようにサンプル作成機能があるので，今回はそちらでビルド対象 A
OpenAPI等のジェネレータツールによる更新作業の自動化、失敗時の自動ロールバックの実現 - Qiita
こんにちは、 最近はOpenAPIやgRPCであったり、それにまつわるジェネレータツールがとても熱いですね。 新規にジェネレータを走らせるのは何の憂いもなく素晴らしいのですが、 開発が進むにつれて、ディレクトリ構造が追加、変更されたり、中間処理を挟んだりと、素のジェネレータでは対応できない場合があります。 また、複数のジェネレータを使う場合、それぞれのジェネレータのご機嫌を伺わなければならない状況が発生し、そもそも更新作業にはジェネレータを使わないようになる場合も多いと思います。 ジェネレートした結果が意図した結果にならなかった場合、その問題を解決するために、いちいちGit操作を行ったり、例えば、ある段階のcommitを取り消したりrebaseしたりする操作を行うとそれだけで丸1日が潰れてしまう経験をお持ちの方もいるのではないでしょうか。 今回は、ジェネレータをもっと効率的に使うために、ジ
Contract-Driven Development / OpenAPI で加速する契約駆動開発 - Qiita
はじめに OpenAPIで仕様書を書いておくと、エコシステムによって色々開発を加速できるよということを記事にします。 具体的なコードなどは、imunew/openapi-ecosystemに置いときますので、参照ください。 定義ファイルの分割・ビルド Swagger-CLIのbundleコマンドを使うと複数の定義ファイルから一つのOpenAPI仕様書を作成することができます。 具体的には、Swagger-CLIを利用します。 詳しいことは、以下の記事を参照ください。 OpenAPI ファイルを 分割 / 結合 する 方法 Swagger-UIで仕様書をブラウザに表示する Swagger-UIで仕様書をブラウザに表示することができます。 具体的には、Swagger-UIを利用します。 詳しいことは、以下の記事を参照ください。 DockerでSwagger UIを起動してAPI仕様書をブラウザ
Spring+DDDでのアプリケーションアーキテクチャとテスト戦略 - Qiita
GxPのやすば（@nyasba） です。 本記事はグロースエクスパートナーズアドベントカレンダー 2日目の記事です 弊社が得意とする継続的な開発のためには保守性が高いアプリケーションにしていく必要があり、今自分が関わっている案件では**DDD（ドメイン駆動設計）**を採用しています。 今日はJava/SpringプロジェクトでDDDを実践する際のアプリケーションのアーキテクチャ（レイヤ構造やパッケージ構成など）とテスト戦略についてまとめてみます。 ※会社としても採用実績はありますが、あくまで個人の思想に基づく内容です。 はじめに Springで開発している案件といっても、レイヤ構成やパッケージの切り方やそれに伴うテスト戦略は様々です。弊社内でも特に標準が定められているわけではありませんので、案件によって切り方が違うのが現状です。 パッケージの切り方自体はコードを見れば理解できるものですが、
GitHub Actionsを使ってAPI設計をフロントエンドと共有する話 - Qiita
はじめに 以下記事を読んで、OpenAPI Specをもっとフロントエンド側で活用できたら良いなと思いました。 そこで、同じようにGitHub Actionsを使って、GitHub PagesにReDocを配置、Mock Server（Prism）をCloud Runへデプロイしてみることにしました。 なお、Mock Server（Prism）のデプロイ先をCloud Runにしたのは、最小インスタンスを0にする（つまり、アクセスが無い時はインスタンスが落ちている状態にできる）ことができ、課金を抑えられると思ったからです。 ReDocとは？ ReDocは、OpenAPI Specからドキュメントを生成してくれるツールです。 同じようなツールで、Swagger UIもありますが、Swagger UIはリファレンス要素が強く、ReDocはガイド要素が強い（見易さ重視）印象を受けました。そのため
ほぼゼロから学ぶFlutterアプリ開発 - Qiita
はじめに アプリ開発のエンジニアがフロントエンド・バックエンド・インフラというように専業化されて、様々な開発言語やツールが生まれた現在において、バックエンドエンジニアが戦々恐々ながらにフロントエンドの開発に触れたらどこまでやれるのか、実践してみました。 技術選定および条件 今では数多くあるフロントエンド開発における術として、今回はFlutterを選択しました。 Flutterとは・・・ Googleによって開発されたフリーかつオープンソースのUIのSDK。 単一のコードベースから、Android、iOS、Linux、macOS、Windows向けのクロスプラットフォームアプリケーションを開発することができる。 FlutterではDart言語を用いる。 DartはJavaScriptのような動的型付け言語でありながら、C#のような静的型付け言語の利点も兼ね備えたオープンソースのプログラミング
【pytest】をFlask+docker開発で初めて使ってみた - Qiita
Flask + docker-composeでのWebアプリ開発に初めてpytestを使用しました。 その際のテストファイルと、設定内容をザックリまとめました。 親の記事はコチラとなります。 ■Flask+Docker+Vue.js+AWS...でゲームWebAppを作ってみた。 ■Githubにソースコード公開しています テスト書くとこんなに良い事ある 今まで、テストプログラムを避けていた人生でした 偶然ですが、テストを必要としないプロジェクトばかりで使う機会が無かったといえば言い訳ですが、心のなかで「あー、本当はテストとか書いといた方が良いんだろうなー」と思いつつも、重い腰が持ち上がらず。。。 そんな方は、私だけでなく多いと思います！ 心機一転でテストを書こうと決心したのは、こんなメリットがあります。 テストコードを書くメリット コード変更した際に、挙動確認が簡単&確実になる。 テスト
GitHub Actionsを用いた自動テストの実行と結果集計 - Qiita
1. はじめに GitHub Actionsを用いて自動テストの実行と結果の集計を行う方法を説明します。 具体的には、ソースコードがGitHubへpushされたタイミングで、pythonで書かれたテストをpytestを使って実行し、GitHub上に下図のサマリを表示します。 今回、GitHub Actionsを初めて使ったので、学習のためにGitHub Actionsの基本についても触れています。 2. GitHub Actionsとは GitHubのCI/CDツール。 push, pull requestなどのGiHub上のアクティビティやスケジュールした時間、外部イベントをトリガーとして、ワークフローを作成できます。 特徴 Linux, macOS, Windowsすべてのコンテナに対応 Node.js, Python, Java, Rubyなど、様々な言語に対応 複数のジョブを並行し
サーバクライアント型のシステムでGraphQLの採用を避けた方が良いと思う理由 - Qiita
自ブログからの引用です。 はじめに GraphQLは非常に高機能なツールである一方、万能が故に本来必要でないケースでも気軽に利用されている印象を受けます。 筆者は同じ組織で同じ目的のために構築されたサーバとクライアントの通信において、GraphQLを採用すべきでないと考えており、本記事ではそのポイントを整理していきます。 なお、本記事ではこのような1対1型のシステムをサーバクライアント型とよびます。 念のために記載しますが、GraphQLは素晴らしい技術であり、本記事はGraphQLを批判するものではありません。 TL;DR (本当の意味で) Code Firstな開発を進めることが難しい サーバクライアント型のシステムでは概念的に両者は一体であるため、両者間の結合を抽象化しない方がよい ドメイン駆動設計を実践するに当たって、ドメインから視点をブラし、モデル駆動開発を阻害する要因となる 開
docusaurusにopenapiを突っ込んでredocで見れるようにする - Qiita
redoc on Docusaurusがしたいと思ったことが結構あります。 理由は単純で、Github PagesでDocusaurus製のドキュメントを作ってさらにRedocを置くとなると場所が足りないからです。 なんか頑張ればサブディレクトリとかでどうにかできなくもなさそうな気がするんですが、仮にできてもそれぞれのドキュメントをまたぐ際などに手間がかかるのであまりスマートではない気がします。 なので、Docusaurus上でいい感じにOpenAPIのファイルを表示してくれるプラグインかなにかはないかと探していました。 そんな中で見つけたのが、redocusaurusです。もう直球ですね。 redocusaurusを試す これです 以下のコマンドを実行します。 npx create-docusaurus@latest <project_name> classic cd <project_
openapi.ymlで開発を効率化しよう！ - Qiita
はじめに この記事はOPENLOGI Advent Calendar 20227日目の記事です！ 私事ですが2022/12月にオープンロジにジョインしました！頑張ります！ まだ入社して間もないので業務にあまり関われてないのですが個人的に最近やったことを紹介させていただきます！ 開発にコミットするAPIドキュメントを作る 皆さんの現場ではAPIドキュメントは開発にコミットしていますか？ 開発にコミットしていないAPIドキュメントの例として、 Swaggerを誰かが作ったけどメンテナンスされていない メンテナンスしているけど誰も見ていない メンテナンスしているけど信頼性が担保されていないので使えない みたいな状態になっていませんか？ APIドキュメントを書くと何がいいの？ APIドキュメントって何に使うの？と思うエンジニアも意外と多いのではないでしょうか 実際SwaggerやStoplight
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PCI DSSの観点から見た セキュアなJavaアプリケーション開発