On Monday, 30 March 2015 at 23:26:38 UTC, Dicebot wrote:
And if you suggest to build both test and normal build as
part of single
compiler call (building test version silently in the
background) this is
also very confusing addition hardly worth its gain.
Making the format of unittest
On 4/6/15 3:16 PM, Leandro Lucarella wrote:
On Monday, 30 March 2015 at 23:26:38 UTC, Dicebot wrote:
And if you suggest to build both test and normal build as part of
single
compiler call (building test version silently in the background)
this is
also very confusing addition hardly worth its
On Saturday, 4 April 2015 at 19:00:01 UTC, Andrei Alexandrescu
wrote:
On 4/4/15 10:38 AM, Nordlöw wrote:
Please also think about how such a builtin feature would
promote
establishment and usage of D from a robustness and
productivity point of
view.
I do think it's a great idea. Sadly I also
On 4/5/15 4:04 AM, Nordlöw wrote:
On Saturday, 4 April 2015 at 19:00:01 UTC, Andrei Alexandrescu wrote:
On 4/4/15 10:38 AM, Nordlöw wrote:
Please also think about how such a builtin feature would promote
establishment and usage of D from a robustness and productivity point of
view.
I do
On 4/4/15 10:38 AM, Nordlöw wrote:
Please also think about how such a builtin feature would promote
establishment and usage of D from a robustness and productivity point of
view.
I do think it's a great idea. Sadly I also think how I have negative
staff to put to work on it. -- Andrei
On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu
wrote:
In brief: I'd like to transition to a model in which
unittesting is organically part of the build. After all, you
wouldn't want to deploy an application that's failing its
unittests.
Overall a good idea, Andrei.
I take the
On Monday, 30 March 2015 at 23:51:17 UTC, Walter Bright wrote:
I'd rather see DMD automatically pass the expression that
triggered the error
(as it is done in C) to replace this useless Unittest
failure that forces me
to look through the code.
You have to look at the code anyway.
My
On 2015-04-02 21:11, Ary Borenszweig wrote:
We can. But then it becomes harder to understand what's going on. In
RSpec I don't quite understand what's going on really, and I like a bit
of magic but not too much of it.
It's quite straightforward to implement, in Ruby as least. Something
like
On 2015-04-02 23:46, Wyatt wrote:
Dealing with it at work, I find it puts us scarily at the mercy of
regexen in Ruby, which is unsettling to say the least. More pressingly,
the plain English method of writing tests hinders my ability to figure
out what the test is actually trying to do.
On 2015-04-02 22:34, Dicebot wrote:
Oh yeah, looking forward to listening it :) I had an unpleasant
experience of encountering Cucumber when trying to contribute to dstep
so this specific name is like a trigger to me :)
Yeah, I don't like how it ended up in DStep. I'm using it completely
On 2015-04-01 21:31, Dicebot wrote:
P.S. I hate all the Ruby testing facilities, hate with bloody passion.
The unit test framework in the Ruby standard library:
class FooTest
def test_foo_bar
assert 3 == 3
end
end
Looks likes most other testing frameworks out there to me.
--
/Jacob
On 2015-04-01 21:28, Ary Borenszweig wrote:
No, it's actually much simpler but less powerful. This is because the
language is not as dynamic as Ruby. But we'd like to keep things as
simple as possible.
Can't you implement that using macros?
But right now you get these things:
1. You can
On 2015-04-01 21:25, Dicebot wrote:
I 100% disagree. Having built-in unittest blocks have been a huge win
for the language and greatly improved quality of library ecosystem.
Value of standardization and availability is tremendous here.
Only problem is that development of the feature has
On 2015-04-01 21:18, Kapps wrote:
The only issue I have with the way unittests are done right now, is the
incredibly annoying requirement of having a main function and that main
gets called. It makes generic tooling and CI systems much more annoying,
as you have to try and guess whether you
On Thu, 02 Apr 2015 08:37:26 +0200, Jacob Carlborg wrote:
On 2015-04-01 21:25, Dicebot wrote:
I 100% disagree. Having built-in unittest blocks have been a huge win
for the language and greatly improved quality of library ecosystem.
Value of standardization and availability is tremendous
On Thu, 02 Apr 2015 06:52:14 +, ketmar wrote:
p.s. ah, sure, it should be `shared static this()`. %$Y^%@%.
signature.asc
Description: PGP signature
On Wednesday, 1 April 2015 at 18:04:31 UTC, Ary Borenszweig wrote:
However, when you have a big complex project you start having
other needs:
1. Named unit-tests, so you can better find what failed
2. Better error messages for assertions
3. Better output to rerun failed tests
4. Setup and
On Thursday, 2 April 2015 at 20:55:04 UTC, David Gileadi wrote:
On 4/2/15 1:34 PM, Dicebot wrote:
On Wednesday, 1 April 2015 at 20:48:43 UTC, Atila Neves wrote:
On Wednesday, 1 April 2015 at 19:31:37 UTC, Dicebot wrote:
P.S. I hate all the Ruby testing facilities, hate with
bloody passion.
On Thu, Apr 2, 2015 at 12:04 PM, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
...
The way I see it, the notion of having one build with strippable unittests
is a nice idea but technically challenging. It's also low impact - today
concurrent CPU is cheap so
On 4/2/15 2:46 PM, Wyatt wrote:
On Thursday, 2 April 2015 at 20:55:04 UTC, David Gileadi wrote:
Having never used Cucumber but having been interested in it, what was
the unpleasantness?
Dealing with it at work, I find it puts us scarily at the mercy of
regexen in Ruby, which is unsettling to
On 4/2/15 1:34 PM, Dicebot wrote:
On Wednesday, 1 April 2015 at 20:48:43 UTC, Atila Neves wrote:
On Wednesday, 1 April 2015 at 19:31:37 UTC, Dicebot wrote:
P.S. I hate all the Ruby testing facilities, hate with bloody passion.
You're going to _love_ my DConf talk ;) I was expecting that
On Thursday, 2 April 2015 at 20:55:04 UTC, David Gileadi wrote:
Having never used Cucumber but having been interested in it,
what was the unpleasantness?
Dealing with it at work, I find it puts us scarily at the mercy
of regexen in Ruby, which is unsettling to say the least. More
On Wednesday, 1 April 2015 at 20:48:43 UTC, Atila Neves wrote:
On Wednesday, 1 April 2015 at 19:31:37 UTC, Dicebot wrote:
P.S. I hate all the Ruby testing facilities, hate with bloody
passion.
You're going to _love_ my DConf talk ;) I was expecting that
already, you let me know what you
On 2015-04-02 08:52, ketmar wrote:
executable code at module scope isn't really necessary, i believe.
I think so to have the same syntax.
--
/Jacob Carlborg
On Thursday, 2 April 2015 at 06:33:50 UTC, Jacob Carlborg wrote:
On 2015-04-01 21:18, Kapps wrote:
The only issue I have with the way unittests are done right
now, is the
incredibly annoying requirement of having a main function and
that main
gets called. It makes generic tooling and CI
On 4/2/15 11:44 AM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Apr 02, 2015 at 11:19:32AM -0700, Jeremy Powers via Digitalmars-d wrote:
On Wed, Apr 1, 2015 at 7:31 AM, Johannes Totz via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 31/03/2015 19:24, Andrei Alexandrescu wrote:
On 4/2/15 3:32 AM, Jacob Carlborg wrote:
On 2015-04-01 21:28, Ary Borenszweig wrote:
No, it's actually much simpler but less powerful. This is because the
language is not as dynamic as Ruby. But we'd like to keep things as
simple as possible.
Can't you implement that using macros?
We can.
On Thu, Apr 02, 2015 at 11:19:32AM -0700, Jeremy Powers via Digitalmars-d wrote:
On Wed, Apr 1, 2015 at 7:31 AM, Johannes Totz via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 31/03/2015 19:24, Andrei Alexandrescu wrote:
Probably not; we're looking at two different builds. The
On Wed, Apr 1, 2015 at 7:31 AM, Johannes Totz via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 31/03/2015 19:24, Andrei Alexandrescu wrote:
Probably not; we're looking at two different builds. The build to be
deployed has no unittest code at all.
I'm starting to see this
On 2015-03-31 23:12, Atila Neves wrote:
I actually thought about the whole it should fail to build if any of
the unit tests fail idea 2 or 3 weeks ago, so this sounds good.
WRT to the error messages and their recognition by text editors, a
_massive_ improvement would be compiler-assisted
On 31/03/2015 19:24, Andrei Alexandrescu wrote:
On 3/31/15 9:21 AM, qznc wrote:
On Monday, 30 March 2015 at 22:50:21 UTC, Andrei Alexandrescu wrote:
Violent agreement here. I was just saying unittests should be part of
the build process, not the run process. Running unittests and then the
app
On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu
wrote:
This is a tooling issue.
I think D's built-in unittest blocks are a mistake.
Yes, they are simple and for simple functions and algorithms they
work pretty well.
However, when you have a big complex project you start having
On Wednesday, 1 April 2015 at 18:04:31 UTC, Ary Borenszweig wrote:
On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu
wrote:
This is a tooling issue.
I think D's built-in unittest blocks are a mistake.
Yes, they are simple and for simple functions and algorithms
they
work pretty
P.S. I hate all the Ruby testing facilities, hate with bloody
passion.
On Wed, 01 Apr 2015 19:18:52 +, Kapps wrote:
Everything you propose can be done with a custom unittest runner, using
the builtin unittest blocks. Compile-time reflection + UDAs + unittests
is a surprisingly powerful combination, and I don't understand the
proposals to make unittest name
On 2015-04-01 20:04, Ary Borenszweig wrote:
By the way, this is the way we do it in Crystal. The source code
for the spec library is here, if you need some inspiration:
https://github.com/manastech/crystal/tree/master/src/spec . It's
just 687 lines long.
Ahhh, looks like my old buddy RSpec
On 4/1/15 3:57 PM, Jacob Carlborg wrote:
On 2015-04-01 20:04, Ary Borenszweig wrote:
By the way, this is the way we do it in Crystal. The source code
for the spec library is here, if you need some inspiration:
https://github.com/manastech/crystal/tree/master/src/spec . It's
just 687 lines
On Wednesday, 1 April 2015 at 18:04:31 UTC, Ary Borenszweig wrote:
On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu
wrote:
This is a tooling issue.
I think D's built-in unittest blocks are a mistake.
Yes, they are simple and for simple functions and algorithms
they
work pretty
On 03/31/2015 05:12 PM, Atila Neves wrote:
I actually thought about the whole it should fail to build if any of
the unit tests fail idea 2 or 3 weeks ago, so this sounds good.
WRT to the error messages and their recognition by text editors, a
_massive_ improvement would be compiler-assisted
On Wednesday, 1 April 2015 at 18:04:31 UTC, Ary Borenszweig wrote:
On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu
wrote:
This is a tooling issue.
I think D's built-in unittest blocks are a mistake.
Yes, they are simple and for simple functions and algorithms
they
work pretty
On Wednesday, 1 April 2015 at 19:31:37 UTC, Dicebot wrote:
P.S. I hate all the Ruby testing facilities, hate with bloody
passion.
You're going to _love_ my DConf talk ;) I was expecting that
already, you let me know what you thought of them last year!
Atila
On 3/30/15 7:14 PM, Mathias Lang via Digitalmars-d wrote:
As you are entitled to. But I don't see any argument here.
The thing here is you're not forced to build both the unittest version
and the deployed version. It's an opt-in thing. The problem currently is
we format error messages badly
On Tuesday, 31 March 2015 at 08:10:19 UTC, Andy Smith wrote:
A band-aid rather than a solution, but sticking this in
.emacs/init.el will fix up emacs to do the right thing with
asserts (only tested with DMD).
Cheers,
A.
(add-to-list 'compilation-error-regexp-alist
A band-aid rather than a solution, but sticking this in
.emacs/init.el will fix up emacs to do the right thing with
asserts (only tested with DMD).
Cheers,
A.
(add-to-list 'compilation-error-regexp-alist
'(^object\.Exception@\\(.*\\)(\\([0-9]+\\)).*
1 2 )
On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu
wrote:
This is a tooling issue.
...
In brief: I'd like to transition to a model in which
unittesting is organically part of the build. After all, you
wouldn't want to deploy an application that's failing its
unittests.
Detail:
On 2015-03-31 01:15, Mathias Lang via Digitalmars-d wrote:
I'd rather see DMD automatically pass the expression that triggered the
error (as it is done in C) to replace this useless Unittest failure
that forces me to look through the code.
D has the advantage that it catches most errors at CT.
On 2015-03-31 02:46, Andrei Alexandrescu wrote:
Often you need the context.
That should be printed as well [1]
[1] http://thejqr.com/2009/02/06/textmate-rspec-and-dot-spec-party.html
--
/Jacob Carlborg
On 2015-03-31 08:10, Andrei Alexandrescu wrote:
The thing here is you're not forced to build both the unittest version
and the deployed version. It's an opt-in thing. The problem currently is
we format error messages badly so we make Good Things difficult. -- Andrei
It's not difficult. I've
On 2015-03-31 02:49, Rikki Cattermole wrote:
While we are at it, how about improving CTFE to be fully JIT'd and
support calling external code? That way it is only a small leap to add
unittests to be CTFE'd.
It's already possible to run unit tests during compile time as CTFE [1].
[1]
On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu
wrote:
Where I want us to be is a place where unittests are considered
a part of the build; it should be trivial to set things up such
that unittesting is virtually indistinguishable from
compilation and linking.
Something of the
On 3/31/15 4:22 AM, Jacob Carlborg wrote:
On 2015-03-31 08:10, Andrei Alexandrescu wrote:
The thing here is you're not forced to build both the unittest version
and the deployed version. It's an opt-in thing. The problem currently is
we format error messages badly so we make Good Things
On Monday, 30 March 2015 at 22:50:21 UTC, Andrei Alexandrescu
wrote:
Violent agreement here. I was just saying unittests should be
part of the build process, not the run process. Running
unittests and then the app is a bad idea.
Sounds like a good idea to me.
Then -unittest should be enabled
On Tuesday, 31 March 2015 at 15:00:28 UTC, Andrei Alexandrescu
wrote:
Problem is doing that for all editors does not scale. -- Andrei
It's not like the error messages used by DMD are in a
standardized format. So hopefully the editors already recognize
this format. BTW, what about
On 3/31/15 2:48 AM, Kagamin wrote:
On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu wrote:
Where I want us to be is a place where unittests are considered a part
of the build; it should be trivial to set things up such that
unittesting is virtually indistinguishable from
On 3/31/15 9:27 AM, Jacob Carlborg wrote:
On Tuesday, 31 March 2015 at 15:00:28 UTC, Andrei Alexandrescu wrote:
Problem is doing that for all editors does not scale. -- Andrei
It's not like the error messages used by DMD are in a standardized
format. So hopefully the editors already
On 3/31/15 9:21 AM, qznc wrote:
On Monday, 30 March 2015 at 22:50:21 UTC, Andrei Alexandrescu wrote:
Violent agreement here. I was just saying unittests should be part of
the build process, not the run process. Running unittests and then the
app is a bad idea.
Sounds like a good idea to me.
On 3/31/15 1:07 PM, Jacob Carlborg wrote:
On 2015-03-31 20:26, Andrei Alexandrescu wrote:
The idea is to make a SMALL change on our side for a LARGE INSTANT
benefit for everyone. Sigh.
But does the editors handles the current format of the compile errors?
At least all editors I use that
I actually thought about the whole it should fail to build if
any of the unit tests fail idea 2 or 3 weeks ago, so this sounds
good.
WRT to the error messages and their recognition by text editors,
a _massive_ improvement would be compiler-assisted formatting of
the assertion errors. This:
On 2015-03-31 10:16, Andy Smith wrote:
Ah - didn't test for your specific example...
Need..
(add-to-list 'compilation-error-regexp-alist
'(^core\.exception.AssertError@\\(.*\\)(\\([0-9]+\\)).*
1 2 ) )
as well not sure how many variants of these there are but if
On 2015-03-31 20:26, Andrei Alexandrescu wrote:
The idea is to make a SMALL change on our side for a LARGE INSTANT
benefit for everyone. Sigh.
But does the editors handles the current format of the compile errors?
I don't see a reason.
Why wouldn't you want exceptions to be clickable as
Would this change result in just not running main and changing
the default unittest runner output, but still run static
constructors (which then allows you to specify a custom unittest
runner)? If so, I think it's a nice change. I've always found it
quite odd that running unittests still runs
On 3/30/15 3:30 PM, Dicebot wrote:
tl: dr: please, no
We have put quite some effort into fighting default DMD behaviour of
-unittest simply adding to main function and not replacing it. Initially
many applications did run tests on startup because DMD suggested it is a
good idea - some rather
This is a tooling issue.
D builds and messaging are rigged to consider unittests as a special
build followed by a special run of an application.
In brief: I'd like to transition to a model in which unittesting is
organically part of the build. After all, you wouldn't want to deploy an
tl: dr: please, no
We have put quite some effort into fighting default DMD behaviour
of -unittest simply adding to main function and not replacing it.
Initially many applications did run tests on startup because DMD
suggested it is a good idea - some rather bad practical
experience has shown
I'd rather see DMD automatically pass the expression that triggered the
error (as it is done in C) to replace this useless Unittest failure that
forces me to look through the code.
D has the advantage that it catches most errors at CT. You can write a lot
of code and just compile it to ensure
On Monday, 30 March 2015 at 22:50:21 UTC, Andrei Alexandrescu
wrote:
On 3/30/15 3:30 PM, Dicebot wrote:
tl: dr: please, no
We have put quite some effort into fighting default DMD
behaviour of
-unittest simply adding to main function and not replacing it.
Initially
many applications did run
2015-03-31 2:46 GMT+02:00 Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com:
On 3/30/15 4:15 PM, Mathias Lang via Digitalmars-d wrote:
I'd rather see DMD automatically pass the expression that triggered the
error (as it is done in C) to replace this useless Unittest failure
That would be great if we could JIT the unitests at build time...
On 3/30/2015 4:15 PM, Mathias Lang via Digitalmars-d wrote:
I'd rather see DMD automatically pass the expression that triggered the error
(as it is done in C) to replace this useless Unittest failure that forces me
to look through the code.
You have to look at the code anyway.
On 3/30/15 4:15 PM, Mathias Lang via Digitalmars-d wrote:
I'd rather see DMD automatically pass the expression that triggered the
error (as it is done in C) to replace this useless Unittest failure
that forces me to look through the code.
Often you need the context.
D has the advantage that
On 31/03/2015 1:08 p.m., deadalnix wrote:
That would be great if we could JIT the unitests at build time...
While we are at it, how about improving CTFE to be fully JIT'd and
support calling external code? That way it is only a small leap to add
unittests to be CTFE'd.
On 3/30/15 4:26 PM, Dicebot wrote:
Main problem with changing default formatting is that it is pretty hard
to choose one that is 100% right.
It's very easy - format asserts occuring directly in unittests the same
as compilation errors. I don't see why this would be ever debated. -- Andrei
On 31/03/2015 2:07 p.m., deadalnix wrote:
On Tuesday, 31 March 2015 at 00:49:41 UTC, Rikki Cattermole wrote:
On 31/03/2015 1:08 p.m., deadalnix wrote:
That would be great if we could JIT the unitests at build time...
While we are at it, how about improving CTFE to be fully JIT'd and
support
On Tuesday, 31 March 2015 at 00:49:41 UTC, Rikki Cattermole wrote:
On 31/03/2015 1:08 p.m., deadalnix wrote:
That would be great if we could JIT the unitests at build
time...
While we are at it, how about improving CTFE to be fully JIT'd
and support calling external code? That way it is only
On Monday, 30 March 2015 at 23:26:38 UTC, Dicebot wrote:
If it is only format that matters you an always change it via
custom test runner. For example, we do have a test runner that
generates JUnit-compatible XML output for Jenkins - and that
was possible to do with plain `unittest` blocks
On Tue, 31 Mar 2015 03:29:38 +, ketmar wrote:
p.s. $#^^#%! pan is buggy, the previous meant to be the answer to OP
post.
signature.asc
Description: PGP signature
On Mon, 30 Mar 2015 22:30:17 +, Dicebot wrote:
tl: dr: please, no
We have put quite some effort into fighting default DMD behaviour of
-unittest simply adding to main function and not replacing it.
Initially many applications did run tests on startup because DMD
suggested it is a good
77 matches
Mail list logo
