trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jackso...@apache.org
Subject [1/5] trafficserver-qa git commit: Restructure docs
Date Tue, 10 Feb 2015 21:55:10 GMT
Repository: trafficserver-qa
Updated Branches:
  refs/heads/master 5f3f5fb2a -> 1eb2e71eb


Restructure docs


Project: http://git-wip-us.apache.org/repos/asf/trafficserver-qa/repo
Commit: http://git-wip-us.apache.org/repos/asf/trafficserver-qa/commit/1bfad94b
Tree: http://git-wip-us.apache.org/repos/asf/trafficserver-qa/tree/1bfad94b
Diff: http://git-wip-us.apache.org/repos/asf/trafficserver-qa/diff/1bfad94b

Branch: refs/heads/master
Commit: 1bfad94b7066d0f794fb23d8b504fe9fdd547c8b
Parents: 5f3f5fb
Author: Thomas Jackson <jacksontj.89@gmail.com>
Authored: Fri Feb 6 15:27:22 2015 -0800
Committer: Thomas Jackson <jacksontj.89@gmail.com>
Committed: Fri Feb 6 15:27:22 2015 -0800

----------------------------------------------------------------------
 README.rst          | 52 ------------------------------------------------
 TODO.rst            |  4 ++++
 doc/design.rst      | 46 ++++++++++++++++++++++++++++++++++++++++++
 tsqa/environment.py |  1 +
 4 files changed, 51 insertions(+), 52 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/trafficserver-qa/blob/1bfad94b/README.rst
----------------------------------------------------------------------
diff --git a/README.rst b/README.rst
index 5678c03..af9cbe4 100644
--- a/README.rst
+++ b/README.rst
@@ -12,53 +12,6 @@ secondary goal of being generic enough to test other proxies-- this has
come up
 since after writing the majority of code is not ATS specific.
 
 
-=================
-Design Principles
-=================
-The goal of this design is to create a flexible framework to write tests in. Additionaly
-we don't want to duplicate things that already exist. There are quite a few frameworks
-out there that do more for you, but they all come with some restrictions. The idea
-here is to enforce (in the framework) very few restrictions. Instead these restrictions
-should be created as style/testing requirements of the project the tests are for.
-This is done by effectively just creating a variety of helper classes that TestCases
-can sub-class to get some common functionality for free.
-
-
-============
-Architecture
-============
-Due to the flexible design principles at play there is very little in terms of
-architecture, but we'll go over the design of a few of the basic helper concepts.
-
-
-Environment
-============
-One of the common use-cases of a test framework is to build and run the application.
-The Environment is a directory (effectively a root dir) with the source code
-installed in it. In addition to the code this root is also where configs live.
-This means that the Environment object is responsible for maintining any daemons
-or configs that the application needs while testing.
-
-To reduce the amount of work to build environments there is an EnvironmentFactory.
-This Factory class will create all unique builds of an application that it is asked
-for. It will then return a copy of the requested environment to the caller. This
-means that if N tests require the same base environment we only have to compile
-once instead of N times.
-
-
-Endpoint
-========
-Another common requirement for integration testing a proxy is an origin. Not only
-do we need an origin, it is common to test the request/response on the origin as well
-as the client (since the proxy will modify the request/response). To aid in these
-sorts of tests we provide a DynamicHTTPEndpoint class which will create a Flask
-server in a separate thread with APIs to register endpoints and track requests.
-
-
-test_cases
-==========
-These are intended to be test cases that you would subclass to create your own test.
-
 
 Environment Variables
 =====================
@@ -66,8 +19,3 @@ TSQA_LAYOUT_PREFIX: Prefix to create layouts for each test execution (defaults
t
 TSQA_LOG_LEVEL: Log level for TSQA (defaults to INFO)
 TSQA_TMP_DIR: temp directory for building of source (environment factory)
 
-
-====
-TODO
-====
-- abstract out "daemon" from environment. This will make it more generic (less ATS specific)and
make it easy to wrap commands in other commands (such as valgrind)

http://git-wip-us.apache.org/repos/asf/trafficserver-qa/blob/1bfad94b/TODO.rst
----------------------------------------------------------------------
diff --git a/TODO.rst b/TODO.rst
new file mode 100644
index 0000000..5693ae6
--- /dev/null
+++ b/TODO.rst
@@ -0,0 +1,4 @@
+====
+TODO
+====
+- abstract out "daemon" from environment. This will make it more generic (less ATS specific)and
make it easy to wrap commands in other commands (such as valgrind)

http://git-wip-us.apache.org/repos/asf/trafficserver-qa/blob/1bfad94b/doc/design.rst
----------------------------------------------------------------------
diff --git a/doc/design.rst b/doc/design.rst
new file mode 100644
index 0000000..2010405
--- /dev/null
+++ b/doc/design.rst
@@ -0,0 +1,46 @@
+=================
+Design Principles
+=================
+The goal of this design is to create a flexible framework to write tests in. Additionaly
+we don't want to duplicate things that already exist. There are quite a few frameworks
+out there that do more for you, but they all come with some restrictions. The idea
+here is to enforce (in the framework) very few restrictions. Instead these restrictions
+should be created as style/testing requirements of the project the tests are for.
+This is done by effectively just creating a variety of helper classes that TestCases
+can sub-class to get some common functionality for free.
+
+
+============
+Architecture
+============
+Due to the flexible design principles at play there is very little in terms of
+architecture, but we'll go over the design of a few of the basic helper concepts.
+
+
+Environment
+============
+One of the common use-cases of a test framework is to build and run the application.
+The Environment is a directory (effectively a root dir) with the source code
+installed in it. In addition to the code this root is also where configs live.
+This means that the Environment object is responsible for maintining any daemons
+or configs that the application needs while testing.
+
+To reduce the amount of work to build environments there is an EnvironmentFactory.
+This Factory class will create all unique builds of an application that it is asked
+for. It will then return a copy of the requested environment to the caller. This
+means that if N tests require the same base environment we only have to compile
+once instead of N times.
+
+
+Endpoint
+========
+Another common requirement for integration testing a proxy is an origin. Not only
+do we need an origin, it is common to test the request/response on the origin as well
+as the client (since the proxy will modify the request/response). To aid in these
+sorts of tests we provide a DynamicHTTPEndpoint class which will create a Flask
+server in a separate thread with APIs to register endpoints and track requests.
+
+
+test_cases
+==========
+These are intended to be test cases that you would subclass to create your own test.

http://git-wip-us.apache.org/repos/asf/trafficserver-qa/blob/1bfad94b/tsqa/environment.py
----------------------------------------------------------------------
diff --git a/tsqa/environment.py b/tsqa/environment.py
index 15580a6..600dfd4 100644
--- a/tsqa/environment.py
+++ b/tsqa/environment.py
@@ -14,6 +14,7 @@ import logging
 
 log = logging.getLogger(__name__)
 
+
 class EnvironmentFactory(object):
     '''
     Make builds of <SOURCE CODE> with optional env/configure flags


Mime
View raw message