今日から使えるクラウド型 Web脆弱性診断ツール Webアプリケーションの脆弱性診断を 社内で実施しませんか? VAddyならセキュリティ専門家以外の方も 脆弱性診断ができます。 1週間無料トライアルではじめる オンライン個別相談会 実施中!
対象読者 JavaScriptの基本をある程度理解している方 テストコードをこれから書こうと考えている方 継続的インテグレーションで「コードを健康的な状態に保つ」 皆さんはどのように開発したコードのテストとビルドを行っていますか? もう15年ほど前になりますが、筆者が行っていたJavaプロジェクトの方法を紹介しましょう。 テキストエディタでJavaのコードを修正 共有ディレクトリにコピー システムすべてのコードをコンパイル システムすべてのコードをjarファイル化 共有開発環境を手動シャットダウン 共有開発環境に手動ビルド 共有開発環境を手動起動 手動で画面から動作テスト エラーが起きた場合は1.に戻る 箇条書きにするとやることが多いですね。もしかすると古いシステムを開発されている方々は、これと近い方法でテストをしている場合もあるのではないでしょうか。何をやっているかはわかりやすいのですが
入社1年半にして4部署めに突入しました技術推進室の木村です。 遷移としては サービス開発チーム(3ヶ月) → スタートアップ室(3ヶ月) → ガールズメディア事業部(1年) → 技術推進室(10月から~) という感じになってます。 新部署に移りましたが、今後共ご愛顧のほどよろしくお願いします。 ガールズメディア事業部内ではDiaryという日記サービスのAndroid版を一人で作成していましたが、技術推進室ではIRORIというサービスのAPIを、先輩達に囲まれて開発を行ってます。 ガールズメディア時代も2ヶ月ほど別の先輩と一緒に作業していた時期がありましたが、プルリクエストベースでのコードレビューとかはあまり積極的に行ってませんでした。 IRORIでは技術推進室の先輩方に囲まれて新機能をリリースする度にコードレビューをして頂いてます。凄いのとかだと1件のプルリクエストに対して、20件近くコメ
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか?もしくはコードカバレッジだけにとらわれすぎていないでしょうか? 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く