On 2014-05-09 13:57, Dicebot wrote:
This is redundant as D unittest blocks are associated with symbols they
are placed next to.
I prefer to keep my tests in a separate directory.
It introduces bunch of artificial annotations for something that can be
taken care of by a single attribute as a
On Thursday, 8 May 2014 at 18:54:30 UTC, Jacob Carlborg wrote:
I mean, what the h*ll does this unit test tests:
https://github.com/D-Programming-Language/phobos/blob/master/std/numeric.d#L995
It is explained in comments there. And it won't become more
simple if you add some fancy syntax
On Wednesday, 7 May 2014 at 16:09:28 UTC, Atila Neves wrote:
They can. But those descriptions are not included in failing
test output. What I think Jacob might be getting to as well is
that assertEquals or the more RSpec-like foo.should equal 3
is more readable than the raw asserts.
The
On Tuesday, 6 May 2014 at 20:41:01 UTC, Andrei Alexandrescu wrote:
On 5/6/14, 11:27 AM, Dicebot wrote:
On Tuesday, 6 May 2014 at 18:13:01 UTC, Andrei Alexandrescu
wrote:
On 5/6/14, 10:43 AM, Dicebot wrote:
Disk I/O failure throws Exception which can be easily
consumed somewhere
inside tested
On Wednesday, 7 May 2014 at 14:34:41 UTC, Bruno Medeiros wrote:
On 06/05/2014 18:58, Dicebot wrote:
I see no good in trying to unite those very different beasts
and my
experience with existing test libraries has been very
unpleasant in that
regard.
What test libraries/frameworks have you
On Thu, 2014-05-08 at 13:03 +, Dicebot via Digitalmars-d wrote:
[…]
I have C/C++ origins so it was mostly stuff like cppUnit, xUnit
and Boost one as far as I can remember.
The current C++ test framework front runner is probably Phil Nash's
Catch https://github.com/philsquared/Catch
--
On 2014-05-08 14:56, Dicebot wrote:
You don't need artificial pseudo syntax for that.
assert!(==) + named tests is good enough to get the context and for
detailed investigation you need file and line number anyway. Stuff like
RSpec is extreme opposite of KISS.
RSpec uses a syntax that makes
On 06/05/14 20:39, Dicebot wrote:
On Tuesday, 6 May 2014 at 18:28:27 UTC, Jacob Carlborg wrote:
d.
I don't see why would be bad to use unittest for integration tests,
except for the misguided name. It's perfectly to place unittest is
completely different modules and packages. They don't need to
On Wednesday, 7 May 2014 at 06:34:44 UTC, Jacob Carlborg wrote:
So you're saying to use the unittest keyword but with a UDA?
I think this is most reasonable compromise that does not harm
existing system.
Something I already do, but for unit tests. Well my idea for a
testing framework would
On Tuesday, 6 May 2014 at 20:41:01 UTC, Andrei Alexandrescu wrote:
Fail with diagnostic. -- Andrei
..and do that for every single test case which is affected. Which
requires either clear test execution order (including
cross-module test dependencies) or shared boilerplate (which
becomes
On 06/05/2014 18:58, Dicebot wrote:
On Tuesday, 6 May 2014 at 15:54:30 UTC, Bruno Medeiros wrote:
But before we continue the discussion, we are missing am more basic
assumption here: Do we want D to have a Unit-Testing facility, or a
Testing facility?? In other words, do we want to be able to
On 07/05/14 16:05, Dicebot wrote:
Have never liked that fancy description syntax of smart testing
frameworks.
I hate plain unit test blocks with just a bunch of asserts. It's
impossible to know that's being tested.
--
/Jacob Carlborg
On Wed, May 07, 2014 at 04:55:25PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 07/05/14 16:05, Dicebot wrote:
Have never liked that fancy description syntax of smart testing
frameworks.
I hate plain unit test blocks with just a bunch of asserts. It's
impossible to know that's being
On Wednesday, 7 May 2014 at 15:07:20 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, May 07, 2014 at 04:55:25PM +0200, Jacob Carlborg via
Digitalmars-d wrote:
On 07/05/14 16:05, Dicebot wrote:
Have never liked that fancy description syntax of smart
testing
frameworks.
I hate plain unit
On 2014-05-07 17:05, H. S. Teoh via Digitalmars-d wrote:
Huh? Isn't that what unittest blocks are about? To verify that certain
assumed conditions are actually true at runtime?
Verbal descriptions can be put in comments, if need be, can't they?
What Atila said.
--
/Jacob Carlborg
On 30/04/2014 16:43, Andrei Alexandrescu wrote:
Hello,
A coworker mentioned the idea that unittests could be run in parallel
(using e.g. a thread pool).
There has been a lot of disagreement in this discussion of whether
unittests blocks should run in parallel or not. Not everyone is
On 30/04/2014 20:23, Dicebot wrote:
On Wednesday, 30 April 2014 at 18:19:34 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Wed, 30 Apr 2014 17:58:34 +
Atila Neves via Digitalmars-d digitalmars-d@puremagic.com wrote:
Unit tests though, by definition (and I'm aware there are more than
On 01/05/2014 18:12, Steven Schveighoffer wrote:
On Thu, 01 May 2014 10:01:19 -0400, Atila Neves atila.ne...@gmail.com
wrote:
On Thursday, 1 May 2014 at 11:44:12 UTC, w0rp wrote:
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
On 01/05/2014 08:18, Dicebot wrote:
On Wednesday, 30 April 2014 at 21:49:06 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Wed, 30 Apr 2014 21:09:14 +0100
Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Wed, 2014-04-30 at 11:19 -0700, Jonathan M Davis via
On Monday, 5 May 2014 at 18:58:37 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 11:47 AM, Dicebot wrote:
On Monday, 5 May 2014 at 18:29:40 UTC, Andrei Alexandrescu
wrote:
My understanding here is you're trying to make dogma out of
engineering choices that may vary widely across projects and
On Tuesday, 6 May 2014 at 15:54:30 UTC, Bruno Medeiros wrote:
But before we continue the discussion, we are missing am more
basic assumption here: Do we want D to have a Unit-Testing
facility, or a Testing facility?? In other words, do we want to
be able to write automated tests that are
On 5/6/14, 10:43 AM, Dicebot wrote:
Disk I/O failure throws Exception which can be easily consumed somewhere
inside tested control flow resulting in absolutely mysterious test failures.
If you're pointing out full /tmp/ should be nicely diagnosed by the
unittest, I agree. -- Andrei
On 2014-05-06 19:58, Dicebot wrote:
These days I often find myself leaning towards writing mostly
integration tests with only limited amount of unit tests. But writing
good integration test is very different from writing good unit test and
usually implies quite lot of boilerplate. Truth is D
On Tuesday, 6 May 2014 at 18:13:01 UTC, Andrei Alexandrescu wrote:
On 5/6/14, 10:43 AM, Dicebot wrote:
Disk I/O failure throws Exception which can be easily consumed
somewhere
inside tested control flow resulting in absolutely mysterious
test failures.
If you're pointing out full /tmp/
On Tuesday, 6 May 2014 at 18:28:27 UTC, Jacob Carlborg wrote:
d.
I don't see why would be bad to use unittest for integration
tests, except for the misguided name. It's perfectly to place
unittest is completely different modules and packages. They
don't need to be placed inline.
Well I am
On 5/6/14, 11:27 AM, Dicebot wrote:
On Tuesday, 6 May 2014 at 18:13:01 UTC, Andrei Alexandrescu wrote:
On 5/6/14, 10:43 AM, Dicebot wrote:
Disk I/O failure throws Exception which can be easily consumed somewhere
inside tested control flow resulting in absolutely mysterious test
failures.
If
On 1 May 2014 18:40, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 5/1/14, 10:32 AM, Brad Anderson wrote:
It hasn't been C:\TEMP for almost 13 years
About the time when I switched :o). -- Andrei
Amen to that! (Me too)
On Monday, 5 May 2014 at 00:40:41 UTC, Walter Bright wrote:
D has so many language features, we need a higher bar for
adding new ones, especially ones that can be done
straightforwardly with existing features.
Sure, but you'll have to agree that there comes a point where
library solutions
Walter Bright:
D has so many language features, we need a higher bar for
adding new ones, especially ones that can be done
straightforwardly with existing features.
If I am not wrong, all this is needed here is a boolean
compile-time flag, like __is_main_module. I think this is a
small
On Mon, 05 May 2014 10:00:54 +
bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote:
Walter Bright:
D has so many language features, we need a higher bar for
adding new ones, especially ones that can be done
straightforwardly with existing features.
If I am not wrong, all
Jonathan M Davis:
Just because something is done in
python does not mean that it is appropriate for D or that it
requires adding features to D in order to support it.
I agree. On the other hand now I have years of experience in both
language and I still have this need in D.
It makes no
On Mon, 05 May 2014 11:26:29 +
bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote:
Jonathan M Davis:
Such code should be kept separate IMHO.
This means that you now have two modules, so to download them
atomically you need some kind of packaging, like a zip. If your
project
Jonathan M Davis:
Honestly, I wouldn't even consider distributing something that
was only a
single module in size unless it were on the scale of
std.datetime, which we've
generally agreed is too large for a single module.
So, a single module
wouldn't have enough functionality to be worth
However, the community is starting to standardize around Dub as
the standard package manager. Dub makes downloading a package as
easy as editing a JSON file (and it scales such that you can
download a project of any size this way). Did Python have a
proper package manager before this idiom
On Thursday, 1 May 2014 at 16:08:23 UTC, Andrei Alexandrescu
wrote:
It got full because of tests (surprise!). Your actions?
Fix the machine and reduce the output created by the unittests.
It's a simple engineering problem. -- Andrei
You can't. You have not control over that machine you
On Thursday, 1 May 2014 at 19:22:36 UTC, Andrei Alexandrescu
wrote:
On 5/1/14, 11:49 AM, Jacob Carlborg wrote:
On 2014-05-01 17:15, Andrei Alexandrescu wrote:
That's all nice, but I feel we're going gung ho with
overengineering
already. If we give unittests names and then offer people a
On 5/5/14, 8:11 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 16:08:23 UTC, Andrei Alexandrescu wrote:
It got full because of tests (surprise!). Your actions?
Fix the machine and reduce the output created by the unittests. It's a
simple engineering problem. -- Andrei
You can't. You have not
On 5/5/14, 8:16 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 19:22:36 UTC, Andrei Alexandrescu wrote:
On 5/1/14, 11:49 AM, Jacob Carlborg wrote:
On 2014-05-01 17:15, Andrei Alexandrescu wrote:
That's all nice, but I feel we're going gung ho with overengineering
already. If we give unittests
Meta:
However, the community is starting to standardize around Dub as
the standard package manager. Dub makes downloading a package
as easy as editing a JSON file (and it scales such that you can
download a project of any size this way).
Having package manager(s) in Python doesn't make
On Monday, 5 May 2014 at 15:36:19 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 8:11 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 16:08:23 UTC, Andrei Alexandrescu
wrote:
It got full because of tests (surprise!). Your actions?
Fix the machine and reduce the output created by the
unittests.
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should do no I/O because
any sort of I/O can fail because of reasons you don't control from the
test suite is an appropriate generalization of my statement.
Full /tmp is not a problem, there is nothing broken about
On Monday, 5 May 2014 at 16:33:42 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should do no I/O
because
any sort of I/O can fail because of reasons you don't control
from the
test suite is an appropriate generalization of my
On 5/5/14, 10:08 AM, Dicebot wrote:
On Monday, 5 May 2014 at 16:33:42 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should do no I/O because
any sort of I/O can fail because of reasons you don't control from the
test suite is
On Monday, 5 May 2014 at 18:24:43 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 10:08 AM, Dicebot wrote:
On Monday, 5 May 2014 at 16:33:42 UTC, Andrei Alexandrescu
wrote:
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should do no
I/O because
any sort of I/O
On 5/5/14, 11:25 AM, Dicebot wrote:
On Monday, 5 May 2014 at 18:24:43 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 10:08 AM, Dicebot wrote:
On Monday, 5 May 2014 at 16:33:42 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should
On Monday, 5 May 2014 at 18:29:40 UTC, Andrei Alexandrescu wrote:
My understanding here is you're trying to make dogma out of
engineering choices that may vary widely across projects and
organizations. No thanks.
Andrei
I am asking to either suggest an alternative solution or to
clarify
On 5/5/14, 11:47 AM, Dicebot wrote:
On Monday, 5 May 2014 at 18:29:40 UTC, Andrei Alexandrescu wrote:
My understanding here is you're trying to make dogma out of
engineering choices that may vary widely across projects and
organizations. No thanks.
Andrei
I am asking to either suggest an
On 5/2/2014 4:02 AM, bearophile wrote:
Walter Bright:
You've already got it working with version, that's what version is for. Why
add yet another way to do it?
Because I'd like something better. It's an idiom that I have used many times
(around 15-20 times). I'd like the compiler (or build
The D unittest feature has been a mixed bag from the beginning
for me.
When a codebase starts to consider to parallelize the unittests
it's has in many cases become a very expensive to make this
change. If order of execution was not guaranteed this would force
coders to make a better long term
On Friday, 2 May 2014 at 04:28:26 UTC, Ola Fosheim Grøstad wrote:
On Friday, 2 May 2014 at 03:04:39 UTC, Jason Spencer wrote:
If we don't want to consider how we can accommodate both camps
here, then I must at least support Jonathan's modest
suggestion that parallel UTs require active
On Friday, 2 May 2014 at 06:57:46 UTC, w0rp wrote:
You know, executing batches of tests in multiple processes
could be a good compromise. You might still run into filesystem
issues, but if you run a series of tests with a number of
processes at the same time, you can at least guarantee that
On Thursday, 1 May 2014 at 18:38:15 UTC, w0rp wrote:
On Thursday, 1 May 2014 at 17:04:53 UTC, Xavier Bigand wrote:
Le 01/05/2014 16:01, Atila Neves a écrit :
On Thursday, 1 May 2014 at 11:44:12 UTC, w0rp wrote:
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg
wrote:
On 2014-04-30
Walter Bright:
You've already got it working with version, that's what version
is for. Why add yet another way to do it?
Because I'd like something better. It's an idiom that I have used
many times (around 15-20 times). I'd like the compiler (or build
tool) to avoid me to specify two times
On 5/1/14, 8:04 PM, Jason Spencer wrote:
On Thursday, 1 May 2014 at 21:40:38 UTC, Andrei Alexandrescu wrote:
I'll be blunt. What you say is technically sound (which is probably
why you believe it is notable)...
Well, I suppose that's not the MOST insulting brush-off I could hope
for, but it
On 5/1/14, 8:04 PM, Jason Spencer wrote:
On Thursday, 1 May 2014 at 21:40:38 UTC, Andrei Alexandrescu wrote:
I'll be blunt. What you say is technically sound (which is probably
why you believe it is notable)...
Well, I suppose that's not the MOST insulting brush-off I could hope
for, but it
On Friday, 2 May 2014 at 14:59:50 UTC, Andrei Alexandrescu wrote:
I need to make an amend to this because indeed it's more than 2
std deviations away from niceness: I have a long history of
ideas with a poor complexity/usefulness ratio, and I now wish
I'd received such a jolt. -- Andrei
I
On Wed, 30 Apr 2014 22:32:33 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On 4/30/14, 10:01 PM, Jonathan M Davis via Digitalmars-d wrote:
I'm all for parallelizing all unittest blocks that are pure, as
doing so would be safe, but I think that we're making a
On 4/30/14, 11:31 PM, Jonathan M Davis via Digitalmars-d wrote:
On Wed, 30 Apr 2014 22:32:33 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
There are a number of assumptions here: (a) most unittests that can
be effectively parallelized can be actually inferred
On Wednesday, 30 April 2014 at 20:20:26 UTC, Jacob Carlborg wrote:
On 2014-04-30 19:30, Dicebot wrote:
I believe only missing step right now is propagation of UDA's
to RTInfo
when demanded. Everything else can be done as Phobos solution.
I don't see why this is necessary for this case.
It
On Wednesday, 30 April 2014 at 21:49:06 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Wed, 30 Apr 2014 21:09:14 +0100
Russel Winder via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Wed, 2014-04-30 at 11:19 -0700, Jonathan M Davis via
Digitalmars-d
wrote:
unittest blocks just
On Thursday, 1 May 2014 at 01:45:21 UTC, Xavier Bigand wrote:
Splitting all features at an absolute atomic level can be
achieve for open-source libraries, but it's pretty much
impossible for an industrial software. Why being so restrictive
when it's possible to support both vision by extending
On Wed, 30 Apr 2014 23:56:53 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
I don't think undefined behavior is at stake here, and I find the
simile invalid. Thread isolation is a done deal in D and we may as
well take advantage of it. Worse that could happen is
On Wednesday, 30 April 2014 at 21:09:51 UTC, Átila Neves wrote:
I don't know about anyone else, but I make my tests fail a
lot.
I think this is key difference. For me failing unit test is
always exceptional situation.
I TDD a lot. Tests failing are normal. Not only that, I
refactor a lot
On Thursday, 1 May 2014 at 04:50:30 UTC, Jonathan M Davis via
Digitalmars-d wrote:
std.file's unit tests would break immediately. It wouldn't
surprise me
if std.socket's unit tests broke. std.datetime's unit tests
would
probably break on Posix systems, because some of them
temporarily set
the
Walter Bright:
On 4/30/2014 8:54 AM, bearophile wrote:
I'd also like some built-in way (or partially built-in) to use
a module only as
main module (to run its demos) or as module to be imported.
This problem is
solved in Python with the if __name__ == __main__: idiom.
dmd foo.d
On Thu, 01 May 2014 07:26:59 +
Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Thursday, 1 May 2014 at 04:50:30 UTC, Jonathan M Davis via
Digitalmars-d wrote:
std.file's unit tests would break immediately. It wouldn't
surprise me
if std.socket's unit tests broke.
On Thursday, 1 May 2014 at 07:32:43 UTC, bearophile wrote:
This is just the basic idea, and perhaps people suggested
something better than this.
Bye,
bearophile
Yeah I sometimes have commented out main() for that purpose.
Sounds like a useful generic addition.
On Thursday, 1 May 2014 at 07:47:27 UTC, Jonathan M Davis via
Digitalmars-d wrote:
Honestly, I see no problem with std.file's unit tests
triggering I/O.
That's what the module _does_. And it specifically uses the
system's
temp directory so that it doesn't screw with anything else on
the
Am Wed, 30 Apr 2014 13:31:30 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
I'd argue for regular identifiers instead of strings - they can be
seen in stack traces, accessed with __FUNCTION__ etc. -- Andrei
If we actually want to make unittests work just like functions
Am Wed, 30 Apr 2014 22:19:24 +0200
schrieb Jacob Carlborg d...@me.com:
__traits(getUnitTests)
I've always wondered, but never asked: Doesn't __traits(getUnitTests)
usage suffer from the same problem std.benchmark had?
That in order to make it work for all modules you
a) have to explicitly
On Thursday, 1 May 2014 at 08:51:47 UTC, Johannes Pfau wrote:
Am Wed, 30 Apr 2014 22:19:24 +0200
schrieb Jacob Carlborg d...@me.com:
__traits(getUnitTests)
I've always wondered, but never asked: Doesn't
__traits(getUnitTests)
usage suffer from the same problem std.benchmark had?
That in
On Thursday, 1 May 2014 at 08:51:47 UTC, Johannes Pfau wrote:
Am Wed, 30 Apr 2014 22:19:24 +0200
schrieb Jacob Carlborg d...@me.com:
__traits(getUnitTests)
I've always wondered, but never asked: Doesn't
__traits(getUnitTests)
usage suffer from the same problem std.benchmark had?
That in
On 2014-04-30 23:25, Jonathan M Davis via Digitalmars-d wrote:
Sure, that helps, but it's trivial to write a unittest block which
depends on a previous unittest block
There for the tests should be run in random order.
--
/Jacob Carlborg
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we should look into parallelizing all unittests. -- Andrei
I recommend running the tests in random order as well.
--
/Jacob Carlborg
On 2014-04-30 21:12, bearophile wrote:
Are UDAs enough?
@uname(foo) unittest {}
What I'd like is to tie one or more unittests to other entities, like
all the unittests of a specific function.
Something similar is done in RSpec. A BDD framework in Ruby. In D it
might look like this:
On 2014-05-01 11:37, Dicebot wrote:
You only need to make sure all modules are transitively imported from
initial one.
The solution for that would be RMInfo [1], like RTInfo but for modules
instead of types.
[1] https://github.com/D-Programming-Language/dmd/pull/2271
--
/Jacob Carlborg
On 2014-05-01 09:10, Dicebot wrote:
It is not strictly necessary but you can't reliably get all unit test
blocks during compile-time (must be transitively imported) and current
run-time reflection for tests is missing any data but actual function
pointers. I am personally perfectly satisfied
Am Thu, 01 May 2014 09:38:51 +
schrieb Dicebot pub...@dicebot.lv:
On Thursday, 1 May 2014 at 08:51:47 UTC, Johannes Pfau wrote:
You only need to make sure all modules are transitively imported
from initial one. Everything else can be done via recursive
reflection with
Am Wed, 30 Apr 2014 09:02:54 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
To summarize: It provides a function pointer for every unit test to
druntime or user code. This is actually easy to do. Naming tests
requires changes in the parser, but I guess that shouldn't be
On 2014-04-30 22:41, Andrei Alexandrescu wrote:
Yah I think that's possible but I'd like the name to be part of the
function name as well e.g. unittest__%s.
Why is that necessary? To have the correct symbol name when debugging?
I'm using something quite similar to RSpec from the Ruby world:
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we should look into parallelizing all
unittests. -- Andrei
I recommend running the tests in random order as well.
This is a bad idea. Tests could fail only some of
Am Thu, 01 May 2014 13:24:07 +0200
schrieb Jacob Carlborg d...@me.com:
On 2014-05-01 11:37, Dicebot wrote:
You only need to make sure all modules are transitively imported
from initial one.
The solution for that would be RMInfo [1], like RTInfo but for
modules instead of types.
[1]
Le 01/05/2014 09:23, Dicebot a écrit :
On Thursday, 1 May 2014 at 01:45:21 UTC, Xavier Bigand wrote:
Splitting all features at an absolute atomic level can be achieve for
open-source libraries, but it's pretty much impossible for an
industrial software. Why being so restrictive when it's
On Thu, 01 May 2014 11:44:11 +, w0rp wrote:
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we should look into parallelizing all unittests. --
Andrei
I recommend running the tests in random order as well.
On Thursday, 1 May 2014 at 11:44:12 UTC, w0rp wrote:
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we should look into parallelizing all
unittests. -- Andrei
I recommend running the tests in random order as
On Thu, 01 May 2014 09:26:39 -0400, Byron byron.he...@gmail.com wrote:
On Thu, 01 May 2014 11:44:11 +, w0rp wrote:
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we should look into parallelizing all
I dream of a day when TDD crap will be finally discarded and
fade into oblivion.
I think most people who don't like TDD don't fully understand it.
At the same time I think people who like TDD tend to abuse it.
Either way, I like it, do it, and want my workflow to be the best
it is with it.
On 2014-05-01 14:00, Johannes Pfau wrote:
But on a quick look I don't understand how this (or DRT #775) completely
solves the issue.
Now you don't have to import the modules anymore, which is a step
forward, but let's say I want to used this to find all SubClasses of a
class.
Now I can
On Thu, 01 May 2014 00:49:53 -0400, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wed, 30 Apr 2014 20:33:06 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Wed, 30 Apr 2014 13:50:10 -0400, Jonathan M Davis via
Digitalmars-d
On 5/1/14, 1:34 AM, Dicebot wrote:
I have just recently went through some of out internal projects removing
all accidental I/O tests for the very reason that /tmp was full
Well a bunch of stuff will not work on a full /tmp. Sorry, hard to
elicit empathy with a full /tmp :o). -- Andrei
On Thursday, 1 May 2014 at 14:55:50 UTC, Andrei Alexandrescu
wrote:
On 5/1/14, 1:34 AM, Dicebot wrote:
I have just recently went through some of out internal
projects removing
all accidental I/O tests for the very reason that /tmp was full
Well a bunch of stuff will not work on a full /tmp.
On 5/1/14, 4:05 AM, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we should look into parallelizing all unittests. --
Andrei
I recommend running the tests in random order as well.
Great idea! -- Andrei
On 5/1/14, 4:31 AM, Johannes Pfau wrote:
@Andrei do you think having to explicitly import modules to be tested
is an issue?
Well it kinda is. All that's written on the package is unittest, we
should add no fine print to it. -- Andrei
On 5/1/14, 4:35 AM, Johannes Pfau wrote:
Am Wed, 30 Apr 2014 09:02:54 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
To summarize: It provides a function pointer for every unit test to
druntime or user code. This is actually easy to do. Naming tests
requires changes in the
On Thursday, 1 May 2014 at 12:04:57 UTC, Xavier Bigand wrote:
It's just a lot harder when you are under pressure.
I am working for a very small company and our dead lines
clearly doesn't help us with that, and because I am in the
video game industry it's not really critical to have small bugs.
On 5/1/14, 4:41 AM, Jacob Carlborg wrote:
On 2014-04-30 22:41, Andrei Alexandrescu wrote:
Yah I think that's possible but I'd like the name to be part of the
function name as well e.g. unittest__%s.
Why is that necessary? To have the correct symbol name when debugging?
It's nice to have
On 5/1/14, 4:44 AM, w0rp wrote:
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we should look into parallelizing all unittests. --
Andrei
I recommend running the tests in random order as well.
This is a bad
On Thu, 01 May 2014 11:04:31 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/1/14, 4:05 AM, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we should look into parallelizing all unittests. --
Andrei
I recommend running the tests in
On 5/1/14, 8:04 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 14:55:50 UTC, Andrei Alexandrescu wrote:
On 5/1/14, 1:34 AM, Dicebot wrote:
I have just recently went through some of out internal projects removing
all accidental I/O tests for the very reason that /tmp was full
Well a bunch of
On Thursday, 1 May 2014 at 15:37:21 UTC, Andrei Alexandrescu
wrote:
On 5/1/14, 8:04 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 14:55:50 UTC, Andrei Alexandrescu
wrote:
On 5/1/14, 1:34 AM, Dicebot wrote:
I have just recently went through some of out internal
projects removing
all accidental
1 - 100 of 192 matches
Mail list logo
