CleanCut/green 源码下载与部署教程

项目概述

Green is a clean, colorful, fast python test runner.

项目地址

https://github.com/CleanCut/green

项目页面预览

关键指标

• Stars：805
• 主要语言：Python
• License：MIT License
• 最近更新：2024-11-12T22:24:35Z
• 默认分支：main

本站高速下载（国内可用）

点击下载（本站镜像）
– SHA256：3ca5e10fe351a07aa7c3e422aa06611391fa2e62a5b7b52e7f81b49afbf1dd7f

安装部署要点（README 精选）

setup.py command

Green is available as a setup.py runner, invoked as any other setup command:

python setup.py green

This requires green to be present in the setup_requires section of
your setup.py file. To run green on a specific target, use the test_suite
argument (or leave blank to let green discover tests itself):

# setup.py
from setuptools import setup

setup(
    ...
    setup_requires = ['green'],
    # test_suite = "my_project.tests"
)

You can also add an alias to the setup.cfg file, so that python setup.py test actually runs green:

# setup.cfg

[aliases]
test = green

Running Green

To run the unittests, we would change to the parent directory of the project
(/home/user in this example) and then run green proj.

In a real terminal, this output is syntax highlighted

$ green proj
....

Ran 4 tests in 0.125s using 8 processes

OK (passes=4)

Okay, so that’s the classic short-form output for unit tests. Green really
shines when you start getting more verbose:

In a real terminal, this output is syntax highlighted

$ green -vvv proj
Green 4.1.0, Coverage 7.4.1, Python 3.12.2

test_foo
  TestAnswer
.   answer() returns 42
.   answer() returns an integer
  TestSchool
.   test_age
.   test_food

Ran 4 tests in 0.123s using 8 processes

OK (passes=4)

Notes:

1. Green outputs clean, hierarchical output.

2. Test status is aligned on the left (the four periods correspond to four
   passing tests)

3. Method names are replaced with docstrings when present. The first two tests
   have docstrings you can see.

4. Green always outputs a summary of statuses that will add up to the total
   number of tests that were run. For some reason, many test runners forget
   about statuses other than Error and Fail, and even the built-in unittest runner
   forgets about passing ones.

5. Possible values for test status (these match the unittest short status characters exactly)

6. . Pass
7. F Failure
8. E Error
9. s Skipped
10. x Expected Failure
11. u Unexpected pass

Origin Story

Green grew out of a desire to see pretty colors. Really! A big part of the
whole Red/Green/Refactor process in test-driven-development is
actually getting to see red and green output. Most python unit testing
actually goes Gray/Gray/Refactor (at least on my terminal, which is gray
text on black background). That’s a shame. Even TV is in color these days.
Why not terminal output? Even worse, the default output for most test runners
is cluttered, hard-to-read, redundant, and the dang status indicators are not
lined up in a vertical column! Green fixes all that.

But how did Green come to be? Why not just use one of the existing test
runners out there? It’s an interesting story, actually. And it starts with
trial.

trial

I really like Twisted’s trial test runner, though I don’t really have any need
for the rest of the Twisted event-driven networking engine library. I started
professionally developing in Python when version 2.3 was the latest, greatest
version and none of us in my small shop had ever even heard of unit testing
(gasp!). As we grew, we matured and started testing and we chose trial to do
the test running. If most of my projects at my day job hadn’t moved to Python
3, I probably would have just stuck with trial, but at the time I wrote green
trial didn’t run on Python 3
(but since 15.4.0 it does). Trial was and is the foundation for my inspiration
for having better-than-unittest output in the first place. It is a great
example of reducing redundancy (report module/class once, not on every line),
lining up status vertically, and using color. I feel like Green trumped trial
in two important ways: 1) It wasn’t a part of an immense event-driven
networking engine, and 2) it was not stuck in Python 2 as trial was at the
time. Green will obviously never replace trial, as trial has features
necessary to run asynchronous unit tests on Twisted code. After discovering
that I couldn’t run trial under Python 3, I next tried…

nose

I had really high hopes for nose. It seemed to be widely accepted. It seemed
to be powerful. The output was just horrible (exactly the same as unittest’s
output). But it had a plugin system! I tried all the plugins I could find
that mentioned improving upon the output. When I couldn’t find one I liked, I
started developing Green (yes, this Green) as a plugin for nose. I chose the
name Green for three reasons: 1) It was available on PyPi! 2) I like to focus
on the positive aspect of testing (everything passes!), and 3) It made a nice
counterpoint to several nose plugins that had “Red” in the name. I made steady
progress on my plugin until I hit a serious problem in the nose plugin API.
That’s when I discovered that nose is in maintenance
mode —
abandoned by the original developers, handed off to someone who won’t fix
anything if it changes the existing behavior. What a downer. Despite the huge
user base, I already consider nose dead and gone. A project which will not
change (even to fix bugs!) will die. Even the maintainer keeps pointing
everyone to…

nose2

So I pivoted to nose2! I started over developing Green (same repo — it’s in
the history). I can understand the allure of a fresh rewrite as much as the
other guy. Nose had made less-than-ideal design decisions, and this time they
would be done right! Hopefully. I had started reading nose code while writing
the plugin for it, and so I dived deep into nose2. And ran into a mess. Nose2
is alpha. That by itself is not necessarily a problem, if the devs will
release early and often and work to fix things you run into. I submitted a
3-line pull request to fix some
problems where the behavior did
not conform to the already-written documentation which broke my plugin. The
pull request wasn’t initially accepted because I (ironically) didn’t write unit
tests for it. This got me thinking “I can write a better test runner than
this“. I got tired of the friction dealing with the nose/nose2 and decided
to see what it would take to write my own test runner. That brought be to…

unittest

I finally went and started reading unittest (Python 2.7 and 3.4) source code.
unittest is its own special kind of mess, but it’s universally built-in, and
most importantly, subclassing or replacing unittest objects to customize the
output looked a lot easier than writing a plugin for nose and nose2. And it
was, for the output portion! Writing the rest of the test runner turned out to
be quite a project, though. I started over on Green again, starting down the
road to what we have now. A custom runner that subclasses or replaces bits of
unittest to provide exactly the output (and other feature creep) that I wanted.

I had three initial goals for Green:

1. Colorful, clean output (at least as good as trial’s)
2. Run on Python 3
3. Try to avoid making it a huge bundle of tightly-coupled, hard-to-read code.

I contend that I nailed 1. and 2., and ended up implementing a bunch of
other useful features as well (like very high performance via running tests in
parallel in multiple processes). Whether I succeeded with 3. is debatable.
I continue to try to refactor and simplify, but adding features on top of a
complicated bunch of built-in code doesn’t lend itself to the flexibility
needed for clear refactors.

Wait! What about the other test runners?

• pytest — Somehow I never realized pytest existed until a few weeks
  before I released Green 1.0. Nowadays it seems to be pretty popular. If I
  had discovered it earlier, maybe I wouldn’t have made Green! Hey, don’t give
  me that look! I’m not omniscient!

• tox — I think I first ran across tox only a few weeks before I heard of
  pytest. It’s homepage didn’t mention anything about color, so I didn’t try
  using it.

• the ones I missed — Er, haven’t heard of them yet either.

I’d love to hear your feedback regarding Green. Like it? Hate it? Have
some awesome suggestions? Whatever the case, go
open a discussion

常用命令（从 README 提取）

pip3 install green    # To upgrade: "pip3 install --upgrade green"

# From inside your code directory
green

# From outside your code directory
green code_directory

# A specific file
green test_stuff.py

# A specific test inside a large package.
#
# Assuming you want to run TestClass.test_function inside
# package/test/test_module.py ...
green package.test.test_module.TestClass.test_function

# To see all examples of all the failures, errors, etc. that could occur:
green green.examples


# To run Green's own internal unit tests:
green green

verbose       = 2
logging       = True
omit-patterns = myproj*,*prototype*

通用部署说明

1. 下载源码并阅读 README
2. 安装依赖（pip/npm/yarn 等）
3. 配置环境变量（API Key、模型路径、数据库等）
4. 启动服务并测试访问
5. 上线建议：Nginx 反代 + HTTPS + 进程守护（systemd / pm2）

免责声明与版权说明

本文仅做开源项目整理与教程索引，源码版权归原作者所有，请遵循对应 License 合规使用。