From 409eb43cf82d5030f8407674f55073ede2ff99bb Mon Sep 17 00:00:00 2001 From: Thomas Preud'homme Date: Mon, 5 Aug 2019 20:33:48 +0000 Subject: [LNT] Wrap comments and docstrings at 72 chars As per PEP-008, wrap comments and docstrings in the test data creation library at 72 characters. Differential Revision: https://reviews.llvm.org/D65749 git-svn-id: https://llvm.org/svn/llvm-project/lnt/trunk@367923 91177308-0d34-0410-b5e6-96231b3b80d8 --- lnt/testing/__init__.py | 97 +++++++++++++++++++++++++------------------------ 1 file changed, 49 insertions(+), 48 deletions(-) (limited to 'lnt') diff --git a/lnt/testing/__init__.py b/lnt/testing/__init__.py index 6fbc792..1ae63f9 100644 --- a/lnt/testing/__init__.py +++ b/lnt/testing/__init__.py @@ -1,9 +1,9 @@ """ Utilities for working with the LNT test format. -Clients can easily generate LNT test format data by creating Report objects for -the runs they wish to submit, and using Report.render to convert them to JSON -data suitable for submitting to the server. +Clients can easily generate LNT test format data by creating Report +objects for the runs they wish to submit, and using Report.render to +convert them to JSON data suitable for submitting to the server. """ import datetime @@ -15,7 +15,8 @@ try: except ImportError: import simplejson as json -# We define the following constants for use as sample values by convention. +# We define the following constants for use as sample values by +# convention. PASS = 0 FAIL = 1 XFAIL = 2 @@ -32,8 +33,8 @@ def normalize_time(t): class Report: """Information on a single testing run. - In the LNT test model, every test run should define exactly one machine and - run, and any number of test samples. + In the LNT test model, every test run should define exactly one + machine and run, and any number of test samples. """ def __init__(self, machine, run, tests): self.machine = machine @@ -49,9 +50,7 @@ class Report: assert isinstance(t, TestSamples) def update_report(self, new_samples): - """Add extra samples to this report, and update - the end time. - """ + """Add extra samples to this report, and update the end time.""" self.check() self.tests.extend(new_samples) self.run.update_endtime() @@ -59,8 +58,8 @@ class Report: def render(self, indent=4): # Note that we specifically override the encoding to avoid the - # possibility of encoding errors. Clients which care about the text - # encoding should supply unicode string objects. + # possibility of encoding errors. Clients which care about the + # text encoding should supply unicode string objects. return json.dumps({'Machine': self.machine.render(), 'Run': self.run.render(), 'Tests': [t.render() for t in self.tests]}, @@ -70,12 +69,12 @@ class Report: class Machine: """Information on the machine the test was run on. - The info dictionary can be used to describe additional information about - the machine, for example the hardware resources or the operating - environment. + The info dictionary can be used to describe additional information + about the machine, for example the hardware resources or the + operating environment. - Machines entries in the database are uniqued by their name and the entire - contents of the info dictionary. + Machines entries in the database are uniqued by their name and the + entire contents of the info dictionary. """ def __init__(self, name, info={}): self.name = str(name) @@ -90,16 +89,18 @@ class Machine: class Run: """Information on the particular test run. - The start and end time should always be supplied with the run. Currently, - the server uses these to order runs. In the future we will support - additional ways to order runs (for example, by a source revision). - - As with Machine, the info dictionary can be used to describe additional - information on the run. This dictionary should be used to describe - information on the software-under-test that is constant across the test - run, for example the revision number being tested. It can also be used to - describe information about the current state which could be useful in - analysis, for example the current machine load. + The start and end time should always be supplied with the run. + Currently, the server uses these to order runs. In the future we + will support additional ways to order runs (for example, by a source + revision). + + As with Machine, the info dictionary can be used to describe + additional information on the run. This dictionary should be used to + describe information on the software-under-test that is constant + across the test run, for example the revision number being tested. + It can also be used to describe information about the current state + which could be useful in analysis, for example the current machine + load. """ def __init__(self, start_time, end_time, info={}): if start_time is None: @@ -135,28 +136,28 @@ class TestSamples: """Test sample data. The test sample data defines both the tests that were run and their - values. The server automatically creates test database objects whenever a - new test name is seen. - - Test names are intended to be a persistent, recognizable identifier for - what is being executed. Currently, most formats use some form of dotted - notation for the test name, and this may become enshrined in the format in - the future. In general, the test names should be independent of the - software-under-test and refer to some known quantity, for example the - software under test. For example, 'CINT2006.403_gcc' is a meaningful test - name. - - The test info dictionary is intended to hold information on the particular - permutation of the test that was run. This might include variables specific - to the software-under-test . This could include, for example, the compile - flags the test was built with, or the runtime parameters that were used. As - a general rule, if two test samples are meaningfully and directly - comparable, then the should have the same test name but different info - paramaters. - - The report may include an arbitrary number of samples for each test for - situations where the same test is run multiple times to gather statistical - data. + values. The server automatically creates test database objects + whenever a new test name is seen. + + Test names are intended to be a persistent, recognizable identifier + for what is being executed. Currently, most formats use some form of + dotted notation for the test name, and this may become enshrined in + the format in the future. In general, the test names should be + independent of the software-under-test and refer to some known + quantity, for example the software under test. For example, + 'CINT2006.403_gcc' is a meaningful test name. + + The test info dictionary is intended to hold information on the + particular permutation of the test that was run. This might include + variables specific to the software-under-test . This could include, + for example, the compile flags the test was built with, or the + runtime parameters that were used. As a general rule, if two test + samples are meaningfully and directly comparable, then they should + have the same test name but different info paramaters. + + The report may include an arbitrary number of samples for each test + for situations where the same test is run multiple times to gather + statistical data. """ def __init__(self, name, data, info={}, conv_f=float): -- cgit v1.2.3