On Wed, 2010-04-28 at 09:55 -0700, Rogan Creswick wrote:
> On Wed, Apr 28, 2010 at 8:19 AM, Duncan Coutts
> wrote:
> >
> > Yes, it means the testing agent (cabal-install or some other
> > program/system) can do more than simply run all the tests. It means it
> > can enumerate them and not run them
I like this. One area that would be helpful is the ability to run the
tests when different compile flags are used. E.g., the HUnit tests have
different behaviors when compiled with and without optimization; it
would be very handy if I could automate the testing of both cases.
I don't believe
On Wed, Apr 28, 2010 at 12:55 PM, Rogan Creswick wrote:
> On Wed, Apr 28, 2010 at 8:19 AM, Duncan Coutts
> wrote:
>>
>> Yes, it means the testing agent (cabal-install or some other
>> program/system) can do more than simply run all the tests. It means it
>> can enumerate them and not run them (th
If the goal is continuous integration, perhaps it would be sufficient to
require "cabal test" to return an error code of 0 if all tests succeed, and
something else if any of them fail; it can additionally print whatever output
it wants in either case. The continuous integration system would th
Richard G. schrieb:
> I think that formatted plain-text output would be much better than XML,
> something that is human-readable and relatively easy to parse via
> machine. Something similar to the GHC error output would work well
> because developers are familiar with it.
>
> Test :
>
>
On Wed, Apr 28, 2010 at 8:19 AM, Duncan Coutts
wrote:
>
> Yes, it means the testing agent (cabal-install or some other
> program/system) can do more than simply run all the tests. It means it
> can enumerate them and not run them (think a GUI or web interface), run
> a subset of tests, run them in
On Wed, Apr 28, 2010 at 1:24 AM, Richard G. wrote:
> I think that formatted plain-text output would be much better than XML,
> something that is human-readable and relatively easy to parse via machine.
> Something similar to the GHC error output would work well because
> developers are familiar w
On Wed, 2010-04-28 at 10:42 -0400, Thomas Tuegel wrote:
> On Wed, Apr 28, 2010 at 4:54 AM, Duncan Coutts
> wrote:
> > On 28 April 2010 09:24, Richard G. wrote:
> >> I think that formatted plain-text output would be much better than XML,
> >> something that is human-readable and relatively easy to
On Wed, Apr 28, 2010 at 4:54 AM, Duncan Coutts
wrote:
> On 28 April 2010 09:24, Richard G. wrote:
>> I think that formatted plain-text output would be much better than XML,
>> something that is human-readable and relatively easy to parse via machine.
>> Something similar to the GHC error output
On Wed, Apr 28, 2010 at 4:30 AM, Richard G. wrote:
> I think that, rather than having Cabal try to combine the results of
> different frameworks, Cabal should specify interfaces that frameworks need
> to conform to.
>
> E.g., rather than integrating test-framework into Cabal so that HUnit works
>
On 28 April 2010 09:24, Richard G. wrote:
> I think that formatted plain-text output would be much better than XML,
> something that is human-readable and relatively easy to parse via machine.
> Something similar to the GHC error output would work well because
> developers are familiar with it.
I think that, rather than having Cabal try to combine the results of
different frameworks, Cabal should specify interfaces that frameworks
need to conform to.
E.g., rather than integrating test-framework into Cabal so that HUnit
works with it, modify HUnit so it emits the format that Cabal wan
I think that formatted plain-text output would be much better than XML,
something that is human-readable and relatively easy to parse via
machine. Something similar to the GHC error output would work well
because developers are familiar with it.
Test :
E.g.,
Test 1:Passed
src/
My thanks to all of you for your help! I've submitted my proposal as
of this afternoon. I've done my best to ensure that the fruits of
this discussion are represented there.
As an aside, the Google's form has seriously mangled my formatting; if
anyone here has past experience and/or pointers, I'
On Thu, Apr 8, 2010 at 5:53 AM, Duncan Coutts
wrote:
>
> I think it's important to be able to convert into standard or custom
> formats. I've no idea if JUnit XML would make sense as the native
> format. It's plausible.
>
I hadn't really thought about cabal, itself, being a consumer for test
resu
On Wed, 2010-04-07 at 16:09 -0400, Thomas Tuegel wrote:
> On Wed, Apr 7, 2010 at 3:33 PM, Duncan Coutts
> wrote:
> > The importance of this is that it lets us develop improved testsuite
> > interfaces in future. At the moment there are two test interfaces we
> > want to support. One is the simple
On Wed, Apr 7, 2010 at 3:33 PM, Duncan Coutts
wrote:
> The importance of this is that it lets us develop improved testsuite
> interfaces in future. At the moment there are two test interfaces we
> want to support. One is the simple unix style "exit code + stdout"
> interface. This is good because
On Tue, 2010-04-06 at 18:51 -0400, Thomas Tuegel wrote:
> Hello again!
>
> Based on the invaluable feedback I've received, I've made some
> revisions to the proposal I made a few days ago (at the end of this
> post, after my signature). I apologize for the length of my post, but
> I'd like once a
As I understand it, there is only one place in the Cabal package where *build*
dependencies appear, in contrast to lines in the Library and Executable
sections where the *install* dependencies appear (i.e., you might not need all
of the build dependences around merely to use the library or progr
On Tue, Apr 6, 2010 at 9:00 PM, Gregory Crosswhite
wrote:
> Sounds like a good plan to me!
>
> You still need some way to separate out the test dependencies from the main
> build dependencies, though. Perhaps as a separate line in the main Cabal
> header section?
I think I can implement this i
On Tue, Apr 6, 2010 at 5:49 PM, Thomas Tuegel wrote:
>
> Suppose we adopt your suggestion and let test programs be ordinary
> executables in ordinary 'Executable' sections, and make 'Test'
> sections that look like:
>
> > Test foo-1
> > exe-is: foo
> > options: --enable-bar --disable-baz
>
Sounds like a good plan to me!
You still need some way to separate out the test dependencies from the main
build dependencies, though. Perhaps as a separate line in the main Cabal
header section?
Also, per my earlier comment, it would be good if there were also an
"Automatic" option in each t
I apologize for spamming, but it only just occurred to me how to get
the best aspects of both our ideas:
On Tue, Apr 6, 2010 at 8:28 PM, Thomas Tuegel wrote:
> On Tue, Apr 6, 2010 at 7:43 PM, Rogan Creswick wrote:
>> The existing Executable sections may serve the need fine, if we could
>> specif
On 7 April 2010 10:45, Gregory Crosswhite wrote:
> Yes, I personally think that tests which are automatically run should be
> self-contained so that they require no additional intervention by the user.
> However, one could conceivably flag some tests as being "manual" so that they
> are only r
On Apr 6, 2010, at 5:35 PM, Ivan Miljenovic wrote:
> On 7 April 2010 10:28, Thomas Tuegel wrote:
>> Ok, this is the bottom-line that I didn't understand after our first
>> exchange, but I think now I do: I should entirely scrap the second
>> aspect of my proposal and focus exclusively on making
On Apr 6, 2010, at 5:28 PM, Thomas Tuegel wrote:
> On Tue, Apr 6, 2010 at 7:43 PM, Rogan Creswick wrote:
>> test-framework and test-runner both address the second problem, and
>> those solutions can be kept separate, at least for now. Figuring out
>> the best way to specify test commands, depen
On 7 April 2010 10:28, Thomas Tuegel wrote:
> Ok, this is the bottom-line that I didn't understand after our first
> exchange, but I think now I do: I should entirely scrap the second
> aspect of my proposal and focus exclusively on making Cabal build and
> run test programs.
Just as a food for t
On Tue, Apr 6, 2010 at 7:43 PM, Rogan Creswick wrote:
> test-framework and test-runner both address the second problem, and
> those solutions can be kept separate, at least for now. Figuring out
> the best way to specify test commands, dependencies, build/execution
> order, etc. is going to take
On Apr 6, 2010, at 4:40 PM, Thomas Tuegel wrote:
> Now, if you're telling me I'm going off in the wrong direction by
> proposing to integrate a test framework into Cabal itself, that's
> another story. Should I pare down my proposal to only include support
> for a proper 'Test' stanza in the pac
On Tue, Apr 6, 2010 at 4:03 PM, Gregory Crosswhite
wrote:
>
> Rather that starting from scratch, you should strongly consider adapting
> something like test-framework to this task, as it already has done the heavy
> work of creating a way to combine tests from different frameworks into a
> sing
On Tue, Apr 6, 2010 at 7:03 PM, Gregory Crosswhite
wrote:
> Rather that starting from scratch, you should strongly consider adapting
> something like test-framework to this task, as it already has done the heavy
> work of creating a way to combine tests from different frameworks into a
> single
Rather that starting from scratch, you should strongly consider adapting
something like test-framework to this task, as it already has done the heavy
work of creating a way to combine tests from different frameworks into a single
suite and includes such features as displaying a progress bar duri
32 matches
Mail list logo
