Pythonプロジェクトでflat layoutではなくsrc layoutが推奨される理由を理解する - 肉球でキーボード
本文中コード github.com flat layoutとsrc layoutについて Pythonプロジェクトのディレクトリ構成について調べてたところ、flat layoutとsrc layoutという2種類のディレクトリ構成が存在することを知りました。 src レイアウト対フラットレイアウト - Python Packaging User Guide flat layout flat layoutはパッケージフォルダをプロジェクトのルート直下に配置するスタイルです。 flat layoutの有名なpythonプロジェクトだと、 pytorch, django, tensorflow があります。 . ├── README.md ├── pyproject.toml └── my_package/ ├── __init__.py └── module.py src layout 一方、
pytest でテストケース毎に DB を自動的に初期化して、テスト開発体験を向上させる - SalesNow Tech Blog
概要 Web バックエンドのテストコードを書く場合、その多くは DB に依存していることが多いです。 DB 関連のテストは、テストデータの準備やテストケース毎の DB 処理化を適切に行うことが重要ですが、手間がかかる場合あるため、Mock で擬似的にテストしてしまうことも多いかと思います。 ただ、Mock を使ったテストは本質的な問題を検知できない意味のないテストになってしまう可能性があり、可能な限り DB の Mock を行わずに、実際の DB を使用してテストすることが望ましいと考えています。 本記事では、pytest、sqlalchemy、PostgreSQL を使った場合に、テストケース毎に DB を簡単に初期化しつつ、テストケース毎の前提データ登録も簡単うことでテスト開発体験を向上させる方法を紹介します。 前提環境 本記事では、以下の環境を前提として説明いたします。 python
Python(pytest)でテスト書くならfixture,conftest,parametrizeを理解すると世界が一気に変わる
Python(pytest)でテスト書くならfixture,conftest,parametrizeを理解すると世界が一気に変わる 概要 Pythonのテストライブラリといえばpytestが一般的です。 Python標準のuniitestとは異なり、クラスベースではなく関数ベースでテストコードを記述することが一般的ですが、fixture,conftest,parametrizeを理解すると一気に世界が変わり、テスト体験が圧倒的に向上するため、これらの実装方法を紹介します。 リポジトリ 本記事の説明に使用しているサンプルのテスト実装は、以下のリポジトリです。 想定読者 PythonやGitの基本的な使い方を理解している方を想定しているため、基本的な用語説明は省略しています。 環境 エンジニアの利用率の高いmacOSを前提として説明していますので、その他の環境の方は随時読み替えてください。 開
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
Python + pytestで、monkeypatch.setattr()を使ってみた - メモ的な思考的な
pytestでは、monkeypatchを使ってmockを作成できます。 Monkeypatching/mocking modules and environments — pytest documentation モンキーパッチ／モックのモジュールと環境 今回は、monkeypatch.setattr()を使って、 プロダクションコードのメソッドや関数 Python標準モジュールのメソッド を差し替え(mock化)してみた時のメモです。 目次 環境 使い方 プロダクションコードのメソッドを差し替え 標準ライブラリを差し替え 差し替え対象モジュールをimportせずに差し替え 定数の差し替え 複数の引数を持つメソッドを差し替え プライベートメソッドの差し替え 複数の戻り値を持つメソッドの差し替え 例外を送出するように差し替え プロダクションコードがimportしているモジュールの属性を差し
pytest ヘビー🐍ユーザーへの第一歩 - エムスリーテックブログ
蛇行区間にはレールの内側に脱線防止ガードが設置される（本文とは関係ありません）。 こんにちは、エムスリー・エンジニアリングG・基盤開発チーム小本です。 pytest は Python のユニットテストのデファクトスタンダードです。エムスリーでも顧客向けレポートや機械学習でPython＆pytest をヘビー🐍1に使っています。 ですが、実は pytest は、意外と入門のハードルが高い。と言うのも、pytest の公式ドキュメント が、fixtureのような新概念も登場する上、詳細で分量が多いからです（しかも英語）。初心者にいきなり読ませると挫折する可能性大です 2。 そこで、とりあえず使い始めるのに必要そうな情報を日本語でまとめました。 pytest ってどんなライブラリ？ unittest や nose から簡単に移行できる 書き方がシンプル fixture モックもできる プラグイ
単体テストガイドライン — The Pylons Project Documentation (翻訳)
単体テストガイドライン¶ Pylons プロジェクトは、このドキュメントの元となった Tres Seaver によって書かれた Avoiding Temptation: Notes on using unittest effectively に倣ったユニットテスト教義をかなり厳格に守っています。 Note このドキュメントは、ほとんど排他的に 単体 テストを扱います。 結合テストまたは機能テストに対しては私たちは特別の教義を持っていません。 しかし、下記の tips の多くはその文脈でも再利用できます。 悪い単体テストを避けるための tips¶ ある人々は “don’t repeat yourself” をむやみに信じてきました (drink the KoolAid): 私たちは、ほとんどの場合にはコードの繰り返しをしないことが 美徳であることに同意します。しかし、単体テストコードはその例
AWS Lambda（Python） の開発環境・テスト・デプロイ・CI 考察 | DevelopersIO
作るもの ヒーローを管理する Lambda Function を書きます。ヒーロー情報は DynamoDB の ヒーローテーブルに格納するものとします。リポジトリは以下。 * Python Lambda SAM + SAM Local Project コーディング作業 すべてはコードを書くところから始めます。いきなりプロジェクトルートにファイルを置いて書き始めるのも良いですが、後々テストやデプロイも行うことになるので少し整理してみます。以下のようにしました。 . ├── buildspec.yml ├── deploy.sh ├── docker-compose.yml ├── environments │ ├── common.sh │ └── sam-local.json ├── integration_test.sh ├── requirements.txt ├── src
Pythonのテストのパラメータ化にはparameterizedを使うと楽（unittest/pytest/nose/nose2対応） - Blank File
Pythonでテストをパラメータ化した時の書き方を unittest と pytest を使った場合で紹介し、最後にそれらで使えるparameterizedというライブラリを紹介します。 ちなみに私はpytestよりもunittest派です。 はじめに テストを書いていると値が違うだけのケースを複数確認したくなる時があります。 例えば、1 + 1 = 2, 2 + 3 = 5, 32 + (-32) = 0, …などのようなケースです。 これをすべて別のテストケースとして書き下すのは面倒ですしメンテも大変なことになるので、テストフレームワークは大抵こんなテストが簡単にできる仕組みを提供しています。 今回はPythonでよく使われているunittest（標準ライブラリ）とpytestでこれらのテストの書き方を紹介します。 なんでいまさら？と思われそうですが、pytestはともかくunitte
受け入れテストの自動化 ～ OpenCVの「眼」で捉え、Pythonの「脳」が思考し、Appiumの「指」で動かす - Speaker Deck
2017/02/03 JaSST’17 Tokyo
PyPIデビュー2015
Use the left and right arrow keys or click the left and right edges of the page to navigate between slides. (Press 'H' or navigate to hide this message.)
「スマートPythonプログラミング」という本を書きました - CUBE SUGAR CONTAINER
表題の通り Python の本を書いたので、そのご紹介です！ スマートPythonプログラミング: Pythonのより良い書き方を学ぶ 作者: もみじあめ発売日: 2016/03/12メディア: Kindle版この商品を含むブログ (1件) を見る どんな本なの？ ひと言で表すと、自信を持って Python を書けるようになるための本です。 スマートPythonプログラミングなので、略してスマパイって呼んでください。 こんな人におすすめ なんとなく書いてなんとなく動いているコードに不安を覚えている方 入門書は読み終わったけど次に何をして良いか分からない方 Python の初心者から中級者にステップアップしたい方 ベストプラクティスとかアンチパターンって言葉が好きな方 上記に当てはまる方には、本書が少しでも参考になると思います。 どんなことが書いてあるの？ 自分が Python を学び始めた
Go 1.6開発環境整備
しっくり来る所まで来たのでまとめ。 前提 Mac OS X 10.11.3 homebrew Go 1.6 zsh neovim 1.3-dev Go自体の管理 homebrewでインストール。 $ brew install go $ go version go version go1.6 darwin/amd64 $ which go /usr/local/bin/go .zshrcに以下の環境変数を設定。 # for golang export GOVERSION=1.6 export GOPATH=$HOME/.go/$GOVERSION export PATH=$GOPATH/bin:$PATH 一応バージョンをGOPATHに入れて新しいバージョンのGoがリリースされても最初から綺麗にディレクトリ分けてビルドできるようにしてる。後方互換結構大事にしているように見受けられるのであまり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - getmoto/moto: A library that allows you to easily mock out tests based on AWS infrastructure.
今がPython 2からPython 3へ移行するのにベストなタイミング：トークセッションレポート
GitHub - pypa/hatch: Modern, extensible Python project management
複数バージョンのPython向けにCI環境を構築してテストする - Qiita
Issue 3955: maybe doctest doesn't understand unicode_literals? - Python tracker
assertEquals vs. assertEqual in python
Pythonでオブジェクトを返す関数/メソッドをdoctestする - Steel Dragon 14106