1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1TH2MM-0002UT-IP
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Sep 2012 00:53:46 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me
designates 173.246.101.161 as permitted sender)
client-ip=173.246.101.161;
envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me;
Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me)
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1TH2ML-0006IF-Ae for bitcoin-development@lists.sourceforge.net;
Thu, 27 Sep 2012 00:53:46 +0000
Received: from [192.168.1.2] (dhcp00757.north-resnet.unc.edu [152.23.202.249])
by mail.bluematt.me (Postfix) with ESMTPSA id 5BCC54A59;
Thu, 27 Sep 2012 00:53:39 +0000 (UTC)
Message-ID: <1348707206.1193.16.camel@localhost.localdomain>
From: Matt Corallo <bitcoin-list@bluematt.me>
To: steve <steve@mistfpga.net>
Date: Wed, 26 Sep 2012 20:53:26 -0400
In-Reply-To: <5062F4F8.6040504@mistfpga.net>
References: <5061F8CC.9070906@mistfpga.net>
<1348605677.2284.2.camel@localhost.localdomain>
<5062F4F8.6040504@mistfpga.net>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.2 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TH2ML-0006IF-Ae
Cc: Bitcoin Development List <bitcoin-development@lists.sourceforge.net>,
Bill Hees <billhees@gmail.com>
Subject: Re: [Bitcoin-development] Bitcoin Testing Project
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2012 00:53:46 -0000
On Wed, 2012-09-26 at 13:28 +0100, steve wrote:
> Hi Matt,
>
> Glad to have another ninja onboard :)
>
> On 25/09/2012 21:41, Matt Corallo wrote:
> > Although Jenkins may not be the best system, we already have
> > jenkins and pull-tester (which is a dumb python script I wrote to
> > test all incoming pull requests from github).
>
> I have never heard of jenkins before. I need to do some more digging.
> is this the right thing?
>
> https://wiki.jenkins-ci.org/display/JENKINS/Mantis+Plugin
For a mantis plugin, sure, I guess...
>
> Mantis on the other hand, I know exceptionally well. I hate
> duplication of work/data unless absolutely necessary. I will check
> jenkins out (just out of interest what is it actually meant to do? the
> website implies framework, but not what its for)
Jenkins currently just runs the test script after each new commit to
bitcoin (and provides binaries to anyone who wants them), so its pretty
basic (though jenkins has way more features than we use). The bitcoin
one lives at http://jenkins.bluematt.me/
>
> >
> > They both run the same set of scripts, namely those at
> > https://github.com/TheBlueMatt/test-scripts (its pretty basic right
> > now, but since it is on github, I was hoping someone would find
> > the inspiration to add to it).
>
> I will check it out. I wrote a very basic script that wikified the
> changelog,
We currently keep a changelog at https://en.bitcoin.it/wiki/Changelog (I
went back and added tons of logs a while back and it got updated, though
0.7 seems to be missing...) anyway, automating that would be nice...
> and linked to the changes and created wiki pages for the
> testcases.
Having more info on that changelog page would be nice.
> have you seen the stuff I put on bettermeans? bits keep
> vanishing then re appearing.
I have been meaning to catch up with the various attempts at better
bitcoin testing that have started up a few times, but I keep never
getting around to it...
>
> This is the outline of the testing that I setup for 0.7
>
> https://secure.bettermeans.com/projects/4256/wiki
>
> >
> > I dont really care if we keep using jenkins, but I figure we might
> > as well keep all the tests in one place?
>
> Yes, I would love to unify all build testing and testcases into one
> place. I am still on the fence as to including unit tests into this.
> However I do see 3 distinct type of testcases
Even if unit tests are considered separate, having it all run in one
huge test script makes it quite easy to implement new things (like
pull-tester) which test some arbitrary bitcoind commit in the same way
as every other tester.
> 1 - requirements based testcases (requirements based off the current
> block chain rules - these are edge cases and known interoperability
> issues)
The BitcoinjBitcoindComparisonTool.jar file which is run as a part of
the test scripts tries to hit as many block acceptance edge cases as
possible (I'm sure I missed a ton, but it hits a lot too). I've also
been pushing alternate implementation implementors to use it to test
their own implementations.
>
> 2 - Acceptance based testcases - these are testcases that should be
> run for every build. Check out the General Acceptance Tests in the
> wiki link for examples and testcases
>
> 3 - Testcases for reference implementations of things (like multisig -
> i see these working like the /test folder when you install a new perl
> module)
>
> These three things alone are a massive task. and they still wont cover
> everything. I would like to get the workflow so that people can
> sponsor or donate to a specific campaign (eg a new feature is
> implemented, people want it tested so can donate just for that
> campaign [developing testcases, structure, requirements, etc])
>
> Once this is done, I will get to do some exciting stuff (like writing
> fuzzers, automation, etc) unfortunately I do not know python, only perl.
As far as I'm concerned more test cases are more test cases, it may get
unwieldy to maintain, but at least we'd have more test cases :)
In terms of general testing strategies, I really prefer to script it
all, jenkins is quite nice in that it can have slave workers using a
different OS which run their own tests and then report back to the main
jenkins instance. Getting a real Windows slave to run the installer and
test that thoroughly as well as basic Mac things (I know OSX uses a very
different build system...) would be nice (though I dont really have time
to write all those tests...)
re: GUI testing is hard: I've heard Qt's unit test framework is really
powerful and can even include things like click scripting and analysis
of the current views (though, I agree, its still no doubt hard).
Matt
|
