On 2015-04-02 22:31, Dicebot wrote:
I don't think anyone is going to put those in a same inline style as
unittest blocks, so this is not truly relevant. At least I hope so.
You mean inline with the code it tests? No, I hope so too. I put my unit
tests in separate files as well, but that's
On 2015-04-01 21:16, Dicebot wrote:
This is fixed by having smaller modules. If test for a single module
takes more than few blinks of an eye, something is wrong already.
For unit tests, yes. But there are other kinds of tests as well.
Integration, functional, user acceptance test and so on.
On 2015-04-01 20:49, Idan Arye wrote:
So now we just need a way to keep a line number unmodified when you add
lines above it...
I'm not sure what kind of tools you have in mind.
* Print a link which points back to a failing test, requires file and
line information
* Running a specific
On Tuesday, 31 March 2015 at 21:24:20 UTC, Dicebot wrote:
I see no value in test names limited to valid identifiers. It
is only tiny bit more informative than `unittestXXX` we have
already. If we add names, please, let them be proper names that
are easy to read.
I'd rather have the name obey
On Thursday, 2 April 2015 at 06:21:53 UTC, Jacob Carlborg wrote:
On 2015-04-01 21:16, Dicebot wrote:
This is fixed by having smaller modules. If test for a single
module
takes more than few blinks of an eye, something is wrong
already.
For unit tests, yes. But there are other kinds of tests
On Tuesday, 31 March 2015 at 23:53:29 UTC, Andrei Alexandrescu
wrote:
On 3/31/15 4:38 PM, Martin Nowak wrote:
On 04/01/2015 01:11 AM, Andrei Alexandrescu wrote:
The reasonable course is to see how far we can get with a
library-only
solution. Amaury, want to work on that? -- Andrei
In any
On Wednesday, 1 April 2015 at 04:42:33 UTC, Shammah Chancellor
wrote:
I can possibly help with a DIP, but it seems like a very
straightforward request?
-Shammah
Considering the heated debate going on here, I'd say it's not as
straightforward as it seems...
I have PR
https://github.com/D-Programming-Language/phobos/pull/2995 open
since October 2014.
it includes:
* extensible haskell like quickcheck
* benchmarking with names and record keeping to see progress
* offline tool to plot benchmark results with gnuplot
* most std.string functions already
On 2015-03-31 23:08, Idan Arye wrote:
Limiting unittest names to legal identifiers will save a lot of headache
when we set our tools to actually use these names. Matching a legal
identifier in a text stream is much easier than matching an arbitrary
unicode string, even if that string is
On 2015-03-31 11:08, Johannes Pfau wrote:
But here's the problem:
1) The compile time approach requires some kind
of explicit registration of the unittests. At least one mixin per
module.
2) This mixin will usually provide a module constructor. But
using module constructors will
On 2015-03-31 23:14, Idan Arye wrote:
Building by unittest name! Imagine - instead of placing temporary code
in `main` to develop a new feature or fix a bug, you put in a named
unittest and tell your IDE/build-system to only build that unittest(and
whatever code needed for it to run). You
On 2015-04-01 00:02, Idan Arye wrote:
I think you and I work under different assumptions of the goals for this
feature. If we only want unittest names to be something that can be
printed when the unittest runner runs the unittests, than a UDA with a
string is indeed preferable. If we want
On 2015-03-31 15:31, Dicebot wrote:
Most powerful solution would be to simply put attributes for unittest
blocks in runtime information for tests (using RTTI it should be
possible to define such variadic structure in similar manner as D-style
variadic function arguments).
I think the most
On 4/1/15 12:46 AM, Atila Neves wrote:
On Tuesday, 31 March 2015 at 23:53:29 UTC, Andrei Alexandrescu wrote:
On 3/31/15 4:38 PM, Martin Nowak wrote:
On 04/01/2015 01:11 AM, Andrei Alexandrescu wrote:
The reasonable course is to see how far we can get with a library-only
solution. Amaury, want
On Wednesday, 1 April 2015 at 14:05:46 UTC, Jacob Carlborg wrote:
On 2015-03-31 23:14, Idan Arye wrote:
Building by unittest name! Imagine - instead of placing
temporary code
in `main` to develop a new feature or fix a bug, you put in a
named
unittest and tell your IDE/build-system to only
On Wednesday, 1 April 2015 at 14:07:14 UTC, Jacob Carlborg wrote:
On 2015-04-01 00:02, Idan Arye wrote:
I think you and I work under different assumptions of the
goals for this
feature. If we only want unittest names to be something that
can be
printed when the unittest runner runs the
On Wednesday, 1 April 2015 at 18:35:14 UTC, Idan Arye wrote:
The problem is not with running the tests, it's with building
them. In heavily templated libraries(like, for example Phobos),
building without unittests takes seconds and building with
unitetests takes minutes - mainly because the
On 2015-04-01 20:35, Idan Arye wrote:
If we could tell the compiler to only build a single, specific test the
development cycle can become orders of magnitude faster.
There should be a lot of option to run tests:
* Base on a file
* Line number
* Name
* Tag
And so on.
--
/Jacob Carlborg
On 2015-03-30 23:52, Andrei Alexandrescu wrote:
We're having a strong need for named unittests at Facebook for multiple
reasons.
1. We have sophisticated tooling that verifies whether unittests are
flaky. The automated monitor (for e.g. C++) figures whether a given
unittest fails several times
On Monday, 30 March 2015 at 21:57:33 UTC, Andrei Alexandrescu
wrote:
On 3/30/15 2:55 PM, Panke wrote:
I've implemented this in a library and I'm sure others have as
well. Are
you sure, you want a language solution?
With attributes? That might be palatable but only as a standard
solution.
On Monday, 30 March 2015 at 21:52:35 UTC, Andrei Alexandrescu
wrote:
We're having a strong need for named unittests at Facebook for
multiple reasons.
1. We have sophisticated tooling that verifies whether
unittests are flaky. The automated monitor (for e.g. C++)
figures whether a given
Am Mon, 30 Mar 2015 14:52:36 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
We're having a strong need for named unittests at Facebook for
multiple reasons.
As there have already been suggestions to use UDAs I think we should
discuss the fundamental difficulty
I understand the preference to librarize as much as possible, but
I don't think the desire to sacrifice every possible bit of
convenience to avoid the tiniest changes to the language is
always beneficial. I don't say that implementing everything
inside the compiler is good either though, but
On Tuesday, 31 March 2015 at 12:33:31 UTC, Steven Schveighoffer
wrote:
On 3/30/15 5:58 PM, Dicebot wrote:
I'd prefer putting alternative test runner into Phobos instead
which
will support `@name(Something) unittest { }`
Yes, this is one of the benefits I touted 2 years ago when I
asked for
On Tuesday, 31 March 2015 at 11:39:02 UTC, tcak wrote:
On Monday, 30 March 2015 at 21:57:33 UTC, Andrei Alexandrescu
wrote:
On 3/30/15 2:55 PM, Panke wrote:
I've implemented this in a library and I'm sure others have
as well. Are
you sure, you want a language solution?
With attributes? That
On Tuesday, 31 March 2015 at 12:10:15 UTC, w0rp wrote:
On Tuesday, 31 March 2015 at 11:39:02 UTC, tcak wrote:
On Monday, 30 March 2015 at 21:57:33 UTC, Andrei Alexandrescu
wrote:
On 3/30/15 2:55 PM, Panke wrote:
I've implemented this in a library and I'm sure others have
as well. Are
you
On 3/30/15 5:58 PM, Dicebot wrote:
I'd prefer putting alternative test runner into Phobos instead which
will support `@name(Something) unittest { }`
Yes, this is one of the benefits I touted 2 years ago when I asked for
module RTInfo -- we can use this information in the runtime to
On 2015-03-30 21:52:36 +, Andrei Alexandrescu said:
We're having a strong need for named unittests at Facebook for multiple
reasons.
1. We have sophisticated tooling that verifies whether unittests are
flaky. The automated monitor (for e.g. C++) figures whether a given
unittest fails
On Tuesday, 31 March 2015 at 23:11:46 UTC, Andrei Alexandrescu
wrote:
The reasonable course is to see how far we can get with a
library-only solution. Amaury, want to work on that? -- Andrei
If nobody picks it up, I can, but I have very little bandwidth
right now with the work involved on
On Tuesday, March 31, 2015 14:45:49 Idan Arye via Digitalmars-d wrote:
But unittests already have
names(http://dpaste.dzfl.pl/b15e94000f15), so the only required
change is to allow the user to specify that name. This should be
much simpler than adding entirely new fields.
Exactly what I was
On Tuesday, 31 March 2015 at 23:29:28 UTC, Martin Nowak wrote:
On 04/01/2015 12:58 AM, deadalnix wrote:
So now we are going to change the language for this ?
There is a natural name for unitests, the name of the module.
We have
way to break module into pieces in a backward compatible
manner
We need template to use compile time reflection.
Please don't make it all compile time. It is useful to register
tests at runtime as well. Like one tests per SAT instance in a
given SAT benchmark.
Practically only thing we need is a standard way to register a
test function as a unittest
On 3/31/15 5:58 PM, deadalnix wrote:
On Tuesday, 31 March 2015 at 23:11:46 UTC, Andrei Alexandrescu wrote:
The reasonable course is to see how far we can get with a library-only
solution. Amaury, want to work on that? -- Andrei
If nobody picks it up, I can, but I have very little bandwidth
On Monday, 30 March 2015 at 21:58:13 UTC, Dicebot wrote:
I'd prefer putting alternative test runner into Phobos instead
which will support `@name(Something) unittest { }`
Aren't unittest blocks just special functions? If that's the
case, there should be no problem being able to give them
Am Tue, 31 Mar 2015 13:31:58 +
schrieb Dicebot pub...@dicebot.lv:
But here's the problem:
1) The compile time approach requires some kind
of explicit registration of the unittests. At least one
mixin per
module.
2) This mixin will usually provide a module constructor. But
Am Tue, 31 Mar 2015 13:31:58 +
schrieb Dicebot pub...@dicebot.lv:
On Tuesday, 31 March 2015 at 09:08:47 UTC, Johannes Pfau wrote:
Am Mon, 30 Mar 2015 14:52:36 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
We're having a strong need for named unittests at Facebook
:
We're having a strong need for named unittests at Facebook
for
multiple reasons.
Right now the default implementation works by putting
pointers to a
test function into ModuleInfo. We could instead add arrays
of some
'unittest information' struct to ModuleInfo to support names
etc
On 3/31/15 7:55 AM, Meta wrote:
On Monday, 30 March 2015 at 21:58:13 UTC, Dicebot wrote:
I'd prefer putting alternative test runner into Phobos instead which
will support `@name(Something) unittest { }`
Aren't unittest blocks just special functions? If that's the case, there
should be no
On 3/31/15 7:45 AM, Idan Arye wrote:
On Tuesday, 31 March 2015 at 13:34:24 UTC, Dicebot wrote:
On Tuesday, 31 March 2015 at 10:25:57 UTC, Idan Arye wrote:
I understand the preference to librarize as much as possible, but I
don't think the desire to sacrifice every possible bit of convenience
On 3/31/15 1:04 PM, Jacob Carlborg wrote:
On 2015-03-31 16:55, Meta wrote:
Aren't unittest blocks just special functions? If that's the case, there
should be no problem being able to give them names. It seems to me that
it would entail the lifting of a restriction rather than a real language
On Tuesday, 31 March 2015 at 13:34:24 UTC, Dicebot wrote:
On Tuesday, 31 March 2015 at 10:25:57 UTC, Idan Arye wrote:
I understand the preference to librarize as much as possible,
but I don't think the desire to sacrifice every possible bit
of convenience to avoid the tiniest changes to the
On Tuesday, 31 March 2015 at 20:04:01 UTC, Jacob Carlborg wrote:
On 2015-03-31 16:55, Meta wrote:
Aren't unittest blocks just special functions? If that's the
case, there
should be no problem being able to give them names. It seems
to me that
it would entail the lifting of a restriction
Le 31/03/2015 20:21, Andrei Alexandrescu a écrit :
On 3/31/15 7:45 AM, Idan Arye wrote:
On Tuesday, 31 March 2015 at 13:34:24 UTC, Dicebot wrote:
On Tuesday, 31 March 2015 at 10:25:57 UTC, Idan Arye wrote:
I understand the preference to librarize as much as possible, but I
don't think the
On Tuesday, 31 March 2015 at 21:05:40 UTC, Xavier Bigand wrote:
Le 31/03/2015 20:21, Andrei Alexandrescu a écrit :
On 3/31/15 7:45 AM, Idan Arye wrote:
On Tuesday, 31 March 2015 at 13:34:24 UTC, Dicebot wrote:
On Tuesday, 31 March 2015 at 10:25:57 UTC, Idan Arye wrote:
I understand the
UTC, Andrei Alexandrescu
wrote:
We're having a strong need for named unittests at Facebook for
multiple reasons.
1. We have sophisticated tooling that verifies whether
unittests are flaky. The automated monitor (for e.g. C++)
figures whether a given unittest fails several times across
several
On 3/31/15 9:05 AM, w0rp wrote:
On Tuesday, 31 March 2015 at 12:33:31 UTC, Steven Schveighoffer wrote:
On 3/30/15 5:58 PM, Dicebot wrote:
I'd prefer putting alternative test runner into Phobos instead which
will support `@name(Something) unittest { }`
Yes, this is one of the benefits I
On Tuesday, 31 March 2015 at 09:08:47 UTC, Johannes Pfau wrote:
Am Mon, 30 Mar 2015 14:52:36 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
We're having a strong need for named unittests at Facebook for
multiple reasons.
Right now the default implementation works by putting
On Tuesday, 31 March 2015 at 10:25:57 UTC, Idan Arye wrote:
I understand the preference to librarize as much as possible,
but I don't think the desire to sacrifice every possible bit of
convenience to avoid the tiniest changes to the language is
always beneficial. I don't say that implementing
On 3/31/15 9:28 AM, Steven Schveighoffer wrote:
On 3/31/15 9:05 AM, w0rp wrote:
On Tuesday, 31 March 2015 at 12:33:31 UTC, Steven Schveighoffer wrote:
On 3/30/15 5:58 PM, Dicebot wrote:
I'd prefer putting alternative test runner into Phobos instead which
will support `@name(Something)
On 03/31/2015 04:45 PM, Idan Arye wrote:
But unittests already have names(http://dpaste.dzfl.pl/b15e94000f15), so
the only required change is to allow the user to specify that name. This
should be much simpler than adding entirely new fields.
That's the line number, which can't be used as
On 04/01/2015 12:58 AM, deadalnix wrote:
So now we are going to change the language for this ?
There is a natural name for unitests, the name of the module. We have
way to break module into pieces in a backward compatible manner now, so
it's all good.
Are you saying one should split off
On 04/01/2015 01:11 AM, Andrei Alexandrescu wrote:
The reasonable course is to see how far we can get with a library-only
solution. Amaury, want to work on that? -- Andrei
In any case you should talk to Atila Neves who wrote a really good
unittest library.
On 03/31/2015 11:01 PM, Atila Neves wrote:
This is true, but importing modules by name can be code that is
generated. Which is exactly what I do with dtest [1] and unit-threaded
[2]. It's not that big of a deal when it's part of the build system.
Dub does it as well (dub test), because if you
On 3/31/15 4:38 PM, Martin Nowak wrote:
On 04/01/2015 01:11 AM, Andrei Alexandrescu wrote:
The reasonable course is to see how far we can get with a library-only
solution. Amaury, want to work on that? -- Andrei
In any case you should talk to Atila Neves who wrote a really good
unittest
On Tuesday, 31 March 2015 at 21:22:09 UTC, Dicebot wrote:
On Tuesday, 31 March 2015 at 14:45:50 UTC, Idan Arye wrote:
But unittests already have
names(http://dpaste.dzfl.pl/b15e94000f15), so the only
required change is to allow the user to specify that name.
This should be much simpler than
On Tuesday, 31 March 2015 at 20:18:41 UTC, Andrei Alexandrescu
wrote:
On 3/31/15 1:04 PM, Jacob Carlborg wrote:
On 2015-03-31 16:55, Meta wrote:
Aren't unittest blocks just special functions? If that's the
case, there
should be no problem being able to give them names. It seems
to me that
it
On Tuesday, 31 March 2015 at 14:45:50 UTC, Idan Arye wrote:
But unittests already have
names(http://dpaste.dzfl.pl/b15e94000f15), so the only required
change is to allow the user to specify that name. This should
be much simpler than adding entirely new fields.
And does not really help. Of
On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
I'd like to make a DIP for named unittests. Who can help me with that?
Why a DIP, isn't the only question what syntax to use.
unittest (myname) vs. unittest (mynameexpression)
Andrei
There is an ER and an half of an implementation.
https
On 2015-03-31 16:55, Meta wrote:
Aren't unittest blocks just special functions? If that's the case, there
should be no problem being able to give them names. It seems to me that
it would entail the lifting of a restriction rather than a real language
change.
Before:
unittest
{
assert(1 ==
On Tuesday, 31 March 2015 at 14:13:29 UTC, Johannes Pfau wrote:
Am Tue, 31 Mar 2015 13:31:58 +
schrieb Dicebot pub...@dicebot.lv:
But here's the problem:
1) The compile time approach requires some kind
of explicit registration of the unittests. At least one
mixin per
module.
On 3/31/15 2:50 PM, Martin Nowak wrote:
On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
I'd like to make a DIP for named unittests. Who can help me with that?
Why a DIP, isn't the only question what syntax to use.
unittest (myname) vs. unittest (mynameexpression)
Also unittest myname
On 3/31/15 3:58 PM, deadalnix wrote:
On Tuesday, 31 March 2015 at 21:50:56 UTC, Martin Nowak wrote:
On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
I'd like to make a DIP for named unittests. Who can help me with that?
Why a DIP, isn't the only question what syntax to use.
unittest
On 3/31/15 3:28 PM, Andrei Alexandrescu wrote:
On 3/31/15 2:50 PM, Martin Nowak wrote:
On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
I'd like to make a DIP for named unittests. Who can help me with that?
Why a DIP, isn't the only question what syntax to use.
unittest (myname) vs
On Tuesday, 31 March 2015 at 21:50:56 UTC, Martin Nowak wrote:
On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
I'd like to make a DIP for named unittests. Who can help me
with that?
Why a DIP, isn't the only question what syntax to use.
unittest (myname) vs. unittest (mynameexpression
Sounds like something that should be added as a library rather
than the core language.
On 3/30/15 2:59 PM, Panke wrote:
I've implemented this in a library and I'm sure others have as well.
Are you sure, you want a language solution?
Basic principle:
---
unittest {
testCase(a testcase,
{
// actual test code here
});
}
---
Looks a bit too much work.
On Monday, 30 March 2015 at 21:57:33 UTC, Andrei Alexandrescu
wrote:
On 3/30/15 2:55 PM, Panke wrote:
I've implemented this in a library and I'm sure others have as
well. Are
you sure, you want a language solution?
With attributes? That might be palatable but only as a standard
solution.
On Monday, 30 March 2015 at 21:58:13 UTC, Dicebot wrote:
I'd prefer putting alternative test runner into Phobos instead
which will support `@name(Something) unittest { }`
I agree that an annotation (Probably defined in object.d) is the
best way to handle this.
Here's something I don't think
Backward compatibility is not an issue seeing this is a pure
addition.
Andrei
I mean that it lives peacefully alongside normal unittest blocks.
On Monday, 30 March 2015 at 23:02:51 UTC, Mathias Lang wrote:
We do have an `@name` as UDA in Vibe.d, so that'll be a
breaking change
(But `@NamedUnittest(name)` will do).
I also think it should be a library solution.
I can't afford to care about used names for attributes, same as
we still
I've implemented this in a library and I'm sure others have as
well. Are you sure, you want a language solution?
Basic principle:
---
unittest {
testCase(a testcase,
{
// actual test code here
});
}
---
Testcase registers the structure and the runtime just runs the
On Monday, 30 March 2015 at 21:52:35 UTC, Andrei Alexandrescu
wrote:
We're having a strong need for named unittests at Facebook for
multiple reasons.
1. We have sophisticated tooling that verifies whether
unittests are flaky. The automated monitor (for e.g. C++)
figures whether a given
I'd prefer putting alternative test runner into Phobos instead
which will support `@name(Something) unittest { }`
On 3/30/15 2:55 PM, Panke wrote:
I've implemented this in a library and I'm sure others have as well. Are
you sure, you want a language solution?
With attributes? That might be palatable but only as a standard
solution. I'd want to add that to Phobos. -- Andrei
Alexandrescu wrote:
I'd like to make a DIP for named unittests. Who can help me with that?
Andrei
I agree that using library-defined annotations would be a better approach
than language changes. Currently things like tested use the form
@name(AddPeer) unittest { /* ... */ }
Which is nice, because
We're having a strong need for named unittests at Facebook for multiple
reasons.
1. We have sophisticated tooling that verifies whether unittests are
flaky. The automated monitor (for e.g. C++) figures whether a given
unittest fails several times across several commits. Unittests
On Monday, 30 March 2015 at 21:52:35 UTC, Andrei Alexandrescu
wrote:
I'd like to make a DIP for named unittests. Who can help me
with that?
Andrei
I agree that using library-defined annotations would be a better
approach than language changes. Currently things like tested use
the form
On 31/03/2015 10:52 a.m., Andrei Alexandrescu wrote:
We're having a strong need for named unittests at Facebook for multiple
reasons.
1. We have sophisticated tooling that verifies whether unittests are
flaky. The automated monitor (for e.g. C++) figures whether a given
unittest fails several
78 matches
Mail list logo
