はじめに これは Go 4 Advent Calendar 2020 8日目の記事です。 Goのテストにおいて、構造体を含めて型の値を比較したいという場合は往々にしてあります。ロジックの結果はなんらかの値として作用することが多いですから、型の値を比較したい、というのは自然です。私は型の値が等価であるかどうか判定するために、go-cmp というライブラリを使うことが多いです。 github.com しかしGoにおける等価性の仕様は決まっていますし、標準ライブラリの reflect パッケージにも DeepEqual という deeply equal, かどうか判定するメソッドがあります。そこで本記事ではなぜわざわざ go-cmp を使っているのかという理由と、go-cmp を使ったときにどのようにして使うか？という go-cmp の使う上でよく使う以下のTipsを提供したいと思います。 Ti

「Goのtime.Formatによるミリ秒切り捨て」と「MySQLのINSERTによるミリ秒四捨五入」で1秒の誤差が生まれた話GoMySQL 背景 2022年春頃にZOZOTOWNでログイン通知機能とログイン履歴機能をリリースしました。QAのフェーズにおいて、「ログイン通知で表示されるログイン時刻」と「ログイン履歴で表示されるログイン時刻」で最大1秒の誤差が生まれるケースがあることが判明しました。どちらの時刻もミリ秒までは表示しない仕様です。1秒とはいえ、これらの値が不一致なのは問題なので原因調査と対策をしました。 原因 ログイン通知で表示されるログイン時刻 ログイン通知で表示されるログイン時刻は、サーバがログインリクエストを受け付けた時の日時です。つまり、Goのアプリケーション上でのみ処理するデータです。アプリケーションでは、その日時を下のようにFormatし、ミリ秒を切り捨てます。 p

おわかりだろうか？ 追加した実装は下記のようなものだった。 metricExporter, err := otlpmetrichttp.New( ctx, otlpmetrichttp.WithEndpoint(otelAgentAddr), otlpmetrichttp.WithInsecure(), ) if err != nil { return nil, err } meterProvider := metric.NewMeterProvider( metric.WithResource(resource), metric.WithReader( metric.NewPeriodicReader( metricExporter, metric.WithInterval(time.Minute), ), ), ) あとはリクエストのカウントしたりとかそういうシンプルなものです。 co

2020/08/15更新: 「テストの失敗をレポートしたい」と「サブテストの一部のみ実施したい」の章を追加 はじめにTIG の辻です。今回は春の入門祭りということで Go のテストに入門してみよう！という記事です。 書いた背景ですが Go の標準ライブラリのコードリーディング会で testing パッケージにチャレンジしてみましたが、難しすぎてわからん。そもそも Go のテストって何ができるんだっけ？という話になり、基本的な内容をなるべく具体例をまじえながらまとめました。 ざっとどんなことができるんだろう、という index になれば幸いです。 TipsGo に組み込まれているテストの仕組みの中に、ベンチマークに関するテストと Example テストというサンプルコード用のテストも含まれているのですが、この 2 つは対象外にします。基礎的と思われる内容から順に並べてみました。 はじめに T

backendのパフォーマンス測定を実装してみた PR github.com OpenTelemetryとは opentelemetry.io OpenTelemetryは、オープンソースのオブザーバビリティフレームワーク 運用しているアプリのパフォーマンスや健全性が正常な状態か判断するために使用する情報をテレメトリーデータと呼ばれている テレメトリーデータは主に3つのカテゴリに分類される ログ メトリクス トレース OpenTelemetryは、それらのテレメトリデータを収集するためのベンダーに依存しないAPI、ソフトウェア開発キット(SDK)、その他のツールを提供している 使用技術 gqlgen opentelemetry-go Cloud Trace 実装 opentelemetry-goとCloud Traceのコードは以下を参考に実装 cloud.google.com ■ mai

Standard Go Project Layout Translations: 한국어 문서 简体中文 正體中文 简体中文 - ??? Français 日本語 Português Español Română Русский Türkçe Italiano Vietnamese Українська Indonesian Overview This is a basic layout for Go application projects. It's not an official standard defined by the core Go dev team; however, it is a set of common historical and emerging project layout patterns in the Go ecosystem. Some of thes

この記事は、Retty Part1 Advent Calendar 2021の18日目の記事です。 adventar.org こんにちは！RettyOrderの開発リーダーをしている諏訪です。早いもので、アドベントカレンダー書いているともう今年も終わりなんだなぁという気持ちになってきます。 さて、先月Go Conference 2021 Autumnで「GoとGraphQLを使用したサービス開発」というタイトルでRettyOrderの開発の話をしてきました。 ※見逃した方はこちらにアーカイブが残っています。 gocon.jp この発表でAPM周り気になるとのお声をいただいたので、本記事ではgqlgenとAPMのところについて掘り下げていきたいと思います。↑で前提とかの話はしているのでその辺の話は飛ばします。 gqlgenのフック gqlgenでは HandlerExtension というも

TIGの伊藤真彦です。 この記事はGo 1.16連載の1記事目です。 トップバッターとしてgo:embedについて記事を書きます。 go:embedとはプロポーザルとなるissueはこちら、2020年9月のissue作成から約5ヶ月の時を経てgo:embedがリリースに含まれることになりました。 embedとは埋め込みという意味です、その名の通りファイル埋め込みをサポートするためのパッケージです。ファイルを読み込むだけならosやio/ioutilでも行うことが可能ですが、go:embedならではの特徴を説明します。 ちなみにio/ioutilはGo 1.16でdeprecatedになりました、詳しくは連載の他の記事で説明します。 利用方法手始めにサンプルコード、main.goを書いてみました。 main.gopackage main import ( _ "embed" "encoding

はじめに メルペイ エキスパートチームのtenntennです。 メルカリグループでは、毎週金曜日にGo Fridayという社内勉強会を開催しています。 毎週やっているとそれなりに知見が溜まってくるので、定期的に”こぼれ話”としてブログを書こうという話になりました。 今回の記事では、先日のGo Fridayで話題にあがった非公開な機能を使ったテストについて扱いたいと思います。 なお、Goにおけるテストの手法やテストしやすいコードの書き方については、GopherCon 2017でも発表があったmitchellhさんの”Advanced Testing with Go”(スライド/動画)が参考になります。テーブル駆動テストやテストヘルパーなど非常に勉強になるので、まだ見たことのない方はぜひスライドや動画をご覧ください。 TL;DR Goのテストではテスト対象とテストコードを別パッケージにできる

TL; DR Go言語は様々な静的解析ツールがあるが、独自ルールのチェックなどをするには都度ツールを自作する必要がある 1つのツールでより汎用的なチェックができるように、汎用ポリシー言語のRegoでGo言語のAST（抽象構文木）を検査できるようにした 「第一引数に必ずcontext.Contextをとる」というルールをCIでチェックした様子 背景 Go言語では様々な静的解析ツールが提供されており、一般的なベストプラクティスが正しく記述されているか？については既存の静的解析ツールを利用することで概ね必要なチェックをすることができます。例えばセキュアなGoのコーディングをするためのツールとして gosec などがあり、自分も愛用させてもらっています。しかし、ソフトウェア開発におけるコーディング上のルールはベストプラクティスによるものだけでなく、そのソフトウェアやチームに依存したルールというのも

はじめに Go Secure Coding Practice とは コンテンツ一覧 良かったところ 注意すべきところ 最後に はじめに こんにちは。SRE の izzii です。 テックタッチのエンジニア規模もそれなりに拡大し、若手の採用も進んできたため、セキュアコーディングを徹底していきたいという思いがあり、まずは意識改革ということで勉強会を実施しました。セキュアコーディングを目的とした場合には教育だけでなく Static application security testing (SAST) の導入といった方法もあるのですが、まずは自分を含めた開発メンバーにノウハウをインストールすることにしました。セキュアコーディングへの意識が高まれば、いづれ SAST の導入の際に抵抗感も少ないだろうと考えています。いきなり SAST を導入しても、誤検知が煩くて浸透しないリスクもありうると考えてい

概要 この記事を書いている（2019/12/07）時点では、SQLBoilerに、Bulk Insert は実装されていません。 issueやPull Requestはいくつか上がっているようですが、内部に取り込まれる様子がありません。 おそらくその理由は、MySQL、Postgresなどの各種DBにうまく対応しつつ、Insertした複数のstructにIDを埋める、という用件を満たせないからだと推測されます。 （SQLBoilerでは、通常のInsertではInsert後にlast_insert_id を用いて、structのIDにマッピングするように実装されています） Bulk Insert が実装されていないORMは他にもあり、それらもほぼ同様の理由で導入が見送られていそうな気がします。 しかし、実務では、Bulk Insert を使いたい場面は多々発生します。 どうにかうまく、実現

みなさん Fuzz testing ってご存じでしょうか。 人間が作る物は必ずといっていいほどバグが存在します。そしてそのコードをテストする人間も必ずバグを見逃します。 想定していなかった境界値テスト等、人間には先入観という物があり、それが邪魔をして簡単にバグを見逃します。昨今、この様な誰も気付かなかったバグの隙間を突く様な脆弱性が沢山見つかっています。 物によっては重大インシデントに発展する物まであります。 こういった人間では想定できない様なバグを見付けてくれるのが Fuzz testing です。Fuzz testing を実施する事で、ソフトウェアは頑丈になり安全にもなりえます。 本日、Go の master ブランチに Fuzz testing の機能が入りました。 [dev.fuzz] Merge remote-tracking branch 'origin/dev.fuzz'

この記事はQiitaで公開されていました Goでドキュメントを書くとき、一般的にはGoDocを使うと思います。GoDocはシンプルにみえて、実際は色々な書き方をサポートしていますし、ブラウザで単純に表示する以外の読み方もあるので、一通りの方法をまとめてみました。 ドキュメントの書き方 GoDocではソースコードの中に、ある決まった形でコメントを書くと、そのコメントをドキュメントとして扱うことができます。具体的には、パッケージ、型、定数、構造体フィールド、関数・メソッドそれぞれの直前に、空行を入れずコメントを書きます。これらの前に改行を入れてしまうと、ただのコメントになってしまいます。 装飾について GoDocは、大きなドキュメントのために、ヘッダと整形されたテキストの2通り装飾ができます。ただし、リストやテーブルなどは対応していません。 ヘッダ 以下の条件を全て満たせば、ヘッダとして認識さ

標準パッケージと小さいツールの組み合わせで十分テストできますよ的な話 @GolangTestNight(Gunosy.go#10)