Looks like the context is currently passed for nested functions,
not for nested classes.
On Thursday, 5 January 2023 at 13:47:24 UTC, Adam D Ruppe wrote:
On Thursday, 5 January 2023 at 13:27:23 UTC, Vijay Nayar wrote:
Why is this error only found when declaring a class in the
unittest?
A unittest is just a special function, it can run code and have
local variables.
classes and
On Thursday, 21 December 2023 at 10:38:16 UTC, DLearner wrote:
[...]
And now, returning to the problem after several hours Christmas
shopping, everything seems to work perfectly!
This applies to dmd version v2.106.0-dirty under Windows.
Module containing several functions with unittests, no 'main'
function.
Was testing ok some time ago, producing '1/1 modules PASSED
unittests' message.
Today,
```
dmd -main -unittest -run
```
produced nothing,
On Tuesday, 5 December 2023 at 03:36:04 UTC, Steven Schveighoffer
wrote:
Are you using -checkaction=context?
Right.
[...]
For reference:
https://issues.dlang.org/show_bug.cgi?id=22374
https://issues.dlang.org/show_bug.cgi?id=22902
https://issues.dlang.org/show_bug.cgi?id=19937
You even repo
On Friday, 1 December 2023 at 22:00:52 UTC, kdevel wrote:
If I not use -allinst the linker complains when using the
current msgpack-d v1.0.5, e.g.
[...]msgpack-d/src/msgpack/package.d:203: undefined reference
to `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!
If I not use -allinst the linker complains when using the current
msgpack-d v1.0.5, e.g.
[...]msgpack-d/src/msgpack/package.d:203: undefined reference to
`pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!(int)._d_assert_fail!(int)._d_assert_fail(scope const(immut
After switching to dmd v2.105.3 I get this warnings almost
everywhere. Do I really have to fork msgpack-d in order to get
rid of these warnings?
Now I replaced every "in ref" with "in" in my own code but I do
not add that preview flag to the compiler invocation. Is that
safe?
emp_%1.d
echo extern(C) void main() { static foreach(u;
__traits(getUnitTests, __traits(parent, main))) u();} >>
.\__temp_%1.d
dmd -betterC -unittest -i -run .\__temp_%1.d
del .\__temp_%1.d
shift
goto loop
:loopexit
```
On Monday, 5 June 2023 at 18:14:31 UTC, DLearner wrote:
On Monday, 5 June 2023 at 14:25:33 UTC, Mike Parker wrote:
[...]
Thank you for the link, can confirm that:
```
int foo() {
[...]
It's not so easy to deal automatically in case of multiple modules
On Monday, 5 June 2023 at 14:25:33 UTC, Mike Parker wrote:
[...]
The docs say it should work:
https://dlang.org/spec/betterc.html#unittests
[...]
Thank you for the link, can confirm that:
```
int foo() {
return 4;
}
unittest {
assert(foo() != 4, "!= Assert triggered.");
On Monday, 5 June 2023 at 14:29:35 UTC, Richard (Rikki) Andrew
Cattermole wrote:
On 06/06/2023 2:25 AM, Mike Parker wrote:
On Monday, 5 June 2023 at 14:16:39 UTC, ryuukk_ wrote:
In my book this is broken and needs to be fixed, as a user i
don't care about under the hood things, it's a you prob
On Monday, 5 June 2023 at 14:16:39 UTC, ryuukk_ wrote:
In my book this is broken and needs to be fixed, as a user i
don't care about under the hood things, it's a you problem,
user should be able to unit test
The docs say it should work:
https://dlang.org/spec/betterc.html#unittests
So eith
On 06/06/2023 2:25 AM, Mike Parker wrote:
On Monday, 5 June 2023 at 14:16:39 UTC, ryuukk_ wrote:
In my book this is broken and needs to be fixed, as a user i don't
care about under the hood things, it's a you problem, user should be
able to unit test
The docs say it should work:
https://dla
On 06/06/2023 2:16 AM, ryuukk_ wrote:
In my book this is broken and needs to be fixed, as a user i don't care
about under the hood things, it's a you problem, user should be able to
unit test
If you as the user disable key components required for the language to
fully work, its a you problem,
27;t make sense
Currently that is not possible. When you turn on unittests to
be compiled in, that runtime will automatically run them and
then end the program.
The compiler should run the unittest, the compiler should run
the unittest, no matter what flag the programmer is using, in
that case:
mpiled in, that runtime will automatically run them and then end the
program.
The compiler should run the unittest, the compiler should run the
unittest, no matter what flag the programmer is using, in that case:
-betterC
Run what?
Until its in a binary on the target platform (which may n
On Monday, 5 June 2023 at 03:42:20 UTC, ryuukk_ wrote:
[...]
I don't know how all this works, ...
For what it is worth, running _both_ the above code fragments
with:
```
dmd -main -unittest -i -run foo
```
(ie removing the -betterC flag)
produces:
```
foo.d(8): [unittest] != A
On Sunday, 4 June 2023 at 22:14:59 UTC, Richard (Rikki) Andrew
Cattermole wrote:
On 05/06/2023 9:20 AM, ryuukk_ wrote:
Then this needs to be fixed asap, unittest needs to work for
the flags user will use
There is nothing to fix.
You literally do not have any of the druntime code needed to
On 05/06/2023 9:20 AM, ryuukk_ wrote:
Then this needs to be fixed asap, unittest needs to work for the flags
user will use
There is nothing to fix.
You literally do not have any of the druntime code needed to handle
ModuleInfo and hence call via it.
Nor do you have the entry point handled
full D for unittests.
Then this needs to be fixed asap, unittest needs to work for the
flags user will use
D should not advertise broken features to the world with "deal
with it" as workaround, this is not a new language, let's up out
standard of quality
Unittests require some mechanism to execute them.
Druntime provides this capability by default.
You can do it manually by using ``__traits(getUnitTests)`` to get access
to the symbols.
Personally I just use full D for unittests.
Neither:
```
extern(C) int foo() {
return 4;
}
unittest {
assert(foo() != 4, "!= Assert triggered.");
assert(foo() == 4, "== Assert triggered.");
}
```
Nor:
```
int foo() {
return 4;
}
unittest {
assert(foo() != 4, "!= Assert triggered.");
package uses unit_threaded in the
unittest configuration, and only imports unit_threaded in a `version
(unittest)` block. Previously I imported unit_threaded only in the
individual testfunctions themselves, but I thought to reduce some typing.
When my library is now used in another project (that
On Thursday, 5 January 2023 at 16:41:32 UTC, Adam D Ruppe wrote:
On Thursday, 5 January 2023 at 16:38:49 UTC, Vijay Nayar wrote:
Does that class inherit the scope of the function it is
inside, similar to how an inner class does with an outer class?
yup. They can see the local variables from th
On Thursday, 5 January 2023 at 16:38:49 UTC, Vijay Nayar wrote:
Does that class inherit the scope of the function it is inside,
similar to how an inner class does with an outer class?
yup. They can see the local variables from the function.
On Thursday, 5 January 2023 at 13:47:24 UTC, Adam D Ruppe wrote:
On Thursday, 5 January 2023 at 13:27:23 UTC, Vijay Nayar wrote:
Why is this error only found when declaring a class in the
unittest?
A unittest is just a special function, it can run code and have
local variables.
classes and
On Thursday, 5 January 2023 at 13:27:23 UTC, Vijay Nayar wrote:
Why is this error only found when declaring a class in the
unittest?
A unittest is just a special function, it can run code and have
local variables.
classes and structs declared inside it have access to those local
contexts
I've run into an unexpected problem that only seems to happen in
unittests, but not outside of them. Consider the following
example:
```
unittest {
class Ab {
int a;
string b;
static class Builder {
int _a;
string _b;
Builder a(int a) {
_
with
-checkaction=context
* https://issues.dlang.org/show_bug.cgi?id=22374
[REG 2.093] 'import std;' with -checkaction=context causes
link error
* https://issues.dlang.org/show_bug.cgi?id=22902
dmd 2.099 regression: unittest -checkaction=context and
import std.regex causes link er
g.cgi?id=22374
[REG 2.093] 'import std;' with -checkaction=context causes link
error
* https://issues.dlang.org/show_bug.cgi?id=22902
dmd 2.099 regression: unittest -checkaction=context and import
std.regex causes link error
Does `dmd -allinst ...` help in your case?
On Saturday, 28 May 2022 at 23:02:45 UTC, kdevel wrote:
On Friday, 18 March 2022 at 19:42:02 UTC, Anonymouse wrote:
On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote:
If ```import std.regex;``` is commented out or if
```-checkaction=context``` is removed from the cmd line the
unittest
why foo2 is not inferred as scope which is shorter scope then
foo1?
import std.stdio;
@safe:
class Obj {@safe: override string toString() { return "obj";
} }
struct Foo1
{@safe:
this(Obj obj) { this._obj = obj; }
~this() { _obj = null; } // do something with
On Friday, 5 August 2022 at 21:24:13 UTC, Steven Schveighoffer
wrote:
That's not what I was talking about here. I'm talking about
`-vcg-ast` not telling you how it's calling the function.
Thanks for clarification.
I had that in mind but wasn't sure. I first thought it just get
optimized awa
On 8/5/22 3:53 PM, frame wrote:
On Friday, 5 August 2022 at 15:24:16 UTC, Steven Schveighoffer wrote:
oof, I expected this to include the template parameters! I believe it
normally does?
This is a bug that should be filed.
-Steve
Sorry, I don't get what you takling about?
The docs says:
T
On Friday, 5 August 2022 at 15:24:16 UTC, Steven Schveighoffer
wrote:
oof, I expected this to include the template parameters! I
believe it normally does?
This is a bug that should be filed.
-Steve
Sorry, I don't get what you takling about?
The docs says:
The expression:
`a op= b`
is rew
On 8/5/22 11:24 AM, Steven Schveighoffer wrote:
On 8/4/22 10:27 PM, jfondren wrote:
a.opOpAssign(b);
b.opOpAssign(a);
oof, I expected this to include the template parameters! I believe it
normally does?
It does not! I'm genuinely shocked.
```d
void foo(string s, T)(T t) {}
void
On 8/4/22 10:27 PM, jfondren wrote:
The output's not that useful...
```d
import object;
struct S
{
int n;
void opOpAssign(string op)(S rhs) if (op == "/=")
{
n++;
}
void opOpAssign(string op)(S rhs) if (op == "/")
{
}
}
.
The output's not that useful...
```d
import object;
struct S
{
int n;
void opOpAssign(string op)(S rhs) if (op == "/=")
{
n++;
}
void opOpAssign(string op)(S rhs) if (op == "/")
{
}
}
uni
On 8/4/22 9:51 PM, Paul Backus wrote:
On Friday, 5 August 2022 at 01:47:07 UTC, Ruby The Roobster wrote:
I found the issue: opOpAssign isn't getting called at all. I have no
idea why, though.
Given that the example works, the problem must be in some other part of
your code that you haven'
+;
}
void opOpAssign(string op)(S rhs) if (op == "/") {
// do nothing
}
}
unittest {
auto a = S(1), b = S(2);
a /= b;
b /= a;
assert(a.n == 2);
assert(b.n == 3);
}
```
The test fails because the second definition is used (preventing
a "none o
tests:
```d
struct S {
int n;
void opOpAssign(string op)(S rhs) if (op == "/") {
n++;
}
}
unittest {
auto a = S(1), b = S(2);
a /= b;
b /= a;
assert(a.n == 2);
assert(b.n == 3);
}
```
I found the issue: opOpAssign isn't getting called at a
On Friday, 5 August 2022 at 01:47:07 UTC, Ruby The Roobster wrote:
I found the issue: opOpAssign isn't getting called at all. I
have no idea why, though.
Given that the example works, the problem must be in some other
part of your code that you haven't posted. If you can post a more
compl
S rhs) if (op == "/") {
n++;
}
}
unittest {
auto a = S(1), b = S(2);
a /= b;
b /= a;
assert(a.n == 2);
assert(b.n == 3);
}
```
I found the issue: opOpAssign isn't getting called at all. I
have no idea why, though.
Even then, I still have a bug, bu
On Friday, 5 August 2022 at 01:42:23 UTC, jfondren wrote:
On Friday, 5 August 2022 at 01:38:48 UTC, jfondren wrote:
Here's a complete example that passes tests:
```d
struct S {
int n;
void opOpAssign(string op)(S rhs) if (op == "/") {
n++;
}
}
unittest {
On Friday, 5 August 2022 at 01:38:48 UTC, jfondren wrote:
Here's a complete example that passes tests:
```d
struct S {
int n;
void opOpAssign(string op)(S rhs) if (op == "/") {
n++;
}
}
unittest {
auto a = S(1), b = S(2);
a /= b;
b /= a;
h DMD and LDC on Windows x86_64 for dmd v2.100.1
unittest blocks are just anonymous functions. They're not a
special environment and there's nothing you can do here that
wouldn't be necessary in any other user of your code. You have
some other problem (which could very well be a compiler bug.)
On Friday, 5 August 2022 at 01:23:40 UTC, Ruby The Roobster wrote:
[SNIP]
Any function other than an operator overload seems to work fine.
Also, this isn't mentioned in the spec.
Additional Information:
Fails for both DMD and LDC on Windows x86_64 for dmd v2.100.1
How do I get unittests to actually execute operator overloads?
E.g.:
```d
struct Struct
{
void opOpAssign(string op)(Struct rhs) //Assume that the
operator `/=` is implemented here
{
//...
}
}
unittest
{
Struct a = Struct(1);
Struct b = Struct(2);
a /= b
On Friday, 18 March 2022 at 19:42:02 UTC, Anonymouse wrote:
On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote:
If ```import std.regex;``` is commented out or if
```-checkaction=context``` is removed from the cmd line the
unittest passes. Can anybody reproduce this?
https
On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote:
If ```import std.regex;``` is commented out or if
```-checkaction=context``` is removed from the cmd line the
unittest passes. Can anybody reproduce this?
https://run.dlang.io/is/GYDUBz
File an issue, I'd say. The worst thing tha
zstack.d:
```
module zstack;
import std.stdio: writeln;
void bar (int [] i)
{
writeln ("i: ", i);
}
unittest {
int [] arr;
bar (arr);
}
```
zrepo.d:
```
module parser;
import std.regex;
import zstack;
```
```
$ dmd -g -i -unittest -checkaction=context -main -run zr
On Friday, 3 September 2021 at 23:39:44 UTC, Per Nordlöw wrote:
When is a phobos unittest supposed to be qualified with version
`(StdUnittest)`? Ideally, always? I don't see that their
current use is consistenly following a rule. If so, is the
purpose of its presence to reduce the burd
uff) these
kinds of rabbit holes. It's one of the reasons I tried to remove ALL
version(unittest) blocks from phobos that import other modules. But you
just can't remove them all. And any unittests inside templates are going
to compile and get included, even if you don't instantiat
On Saturday, 4 September 2021 at 20:06:27 UTC, Per Nordlöw wrote:
On Saturday, 4 September 2021 at 20:05:17 UTC, Per Nordlöw
wrote:
```sh
time dmd import_std.d -o-
```
should be
```sh
time dmd -unittest import_std.d -o-
```
When you generate the object files, I get 13K vs. 75K from a file
On Saturday, 4 September 2021 at 20:05:17 UTC, Per Nordlöw wrote:
```sh
time dmd import_std.d -o-
```
should be
```sh
time dmd -unittest import_std.d -o-
```
On Saturday, 4 September 2021 at 13:12:49 UTC, Steven
Schveighoffer wrote:
Note that lexing and parsing is extremely quick, and I wouldn't
focus on trying to trim this out, you won't get much
performance out of that.
-Steve
For the record, a D file containing only `import std;` type
checks
On 9/4/21 7:43 AM, Johan wrote:
On Saturday, 4 September 2021 at 03:18:01 UTC, Paul Backus wrote:
On Saturday, 4 September 2021 at 00:09:37 UTC, H. S. Teoh wrote:
This is related to the bogonity of the current behaviour of
-unittest, which compiles *all* unittests of *all* imported modules
On 9/4/21 5:42 AM, Per Nordlöw wrote:
On Saturday, 4 September 2021 at 03:18:01 UTC, Paul Backus wrote:
As Steven Schveighoffer [pointed out][1], Phobos unittests are never
included in user code, regardless of whether `StdUnittest` is used.
Yes, but they are lexed and parsed, right?
Yes, and
On Saturday, 4 September 2021 at 12:40:02 UTC, Per Nordlöw wrote:
Omg. It really seems like it's motivated to do a benchmark with
phobos unittests prefixed with
Should have been a reply to
The "never" is false, https://d.godbolt.org/z/c4oeYM7rG
format as
```d
version (StdUnittest) [QUALIFIER...] unittest
```
instead of current
```d
version (StdUnittest)
[QUALIFIER...] unittest
```
?
On Saturday, 4 September 2021 at 12:31:33 UTC, Dennis wrote:
On Saturday, 4 September 2021 at 09:42:46 UTC, Per Nordlöw
wrote:
Yes, but they are lexed and parsed, right?
Right, but that's the case regardless of `version(StdUnittest)`.
Omg. It really seems like it's motivated to do a benchmar
On Saturday, 4 September 2021 at 12:31:33 UTC, Dennis wrote:
Right, but that's the case regardless of `version(StdUnittest)`.
I don't think so. My guess is that `version(StdUnittest)` does
maximum parsing, maybe only lexing. How can one easily determine
if this is the fact? Behaviour of `prag
On Saturday, 4 September 2021 at 09:42:46 UTC, Per Nordlöw wrote:
Yes, but they are lexed and parsed, right?
Right, but that's the case regardless of `version(StdUnittest)`.
On Saturday, 4 September 2021 at 03:18:01 UTC, Paul Backus wrote:
On Saturday, 4 September 2021 at 00:09:37 UTC, H. S. Teoh wrote:
This is related to the bogonity of the current behaviour of
-unittest, which compiles *all* unittests of *all* imported
modules, even when you're compiling
On Saturday, 4 September 2021 at 03:18:01 UTC, Paul Backus wrote:
As Steven Schveighoffer [pointed out][1], Phobos unittests are
never included in user code, regardless of whether
`StdUnittest` is used.
Yes, but they are lexed and parsed, right?
On Friday, 3 September 2021 at 23:39:44 UTC, Per Nordlöw wrote:
When is a phobos unittest supposed to be qualified with version
`(StdUnittest)`?
Almost never.
`version (StdUnittest)` should be used in Phobos wherever you
would normally use a `version (unittest)` block. It is not for
the
On Saturday, 4 September 2021 at 00:09:37 UTC, H. S. Teoh wrote:
This is related to the bogonity of the current behaviour of
-unittest, which compiles *all* unittests of *all* imported
modules, even when you're compiling user code that has no
interest in Phobos unittests.
Well, n
On Fri, Sep 03, 2021 at 11:39:44PM +, Per Nordlöw via Digitalmars-d-learn
wrote:
> When is a phobos unittest supposed to be qualified with version
> `(StdUnittest)`? Ideally, always? I don't see that their current use
> is consistenly following a rule. If so, is the purpose o
When is a phobos unittest supposed to be qualified with version
`(StdUnittest)`? Ideally, always? I don't see that their current
use is consistenly following a rule. If so, is the purpose of its
presence to reduce the burden of the compiler when the
application using phobos is compiled
e in the unittest section of
a module, it fails with
a segmentation fault and I don't understand why!
unittest blocks are just functions, so this is pretty strange. At
a guess, you have some library setup code and are putting that in
a module with main() instead of in `shared static t
w is a C function for allocating a
new mpdecimal object via
malloc, prototype:
mpd_t *mpd_new(mpd_context_t *ctx);
see the documentation at:
https://www.bytereef.org/mpdecimal/doc/libmpdec/decimals.html?highlight=mpd_new#std:topic-mpd_new
However, if I put the very same code in the unittest sect
On Monday, 16 August 2021 at 22:01:21 UTC, russhy wrote:
remove the .dub folder and try again, as stated in other reply,
might be a cache issue, or something that picks an outdated
file in the cache
Thanks, I'll try that, sadly clear didn't seem to fix it.
remove the .dub folder and try again, as stated in other reply,
might be a cache issue, or something that picks an outdated file
in the cache
On Sunday, 15 August 2021 at 10:32:27 UTC, Rekel wrote:
Note you might need to open the screenshots externally, as they
are cut off by the forum.
This looks like your build system fails to detect file changes
and links outdated .o file(s), or library, which causes a
mismatch between your debu
Note you might need to open the screenshots externally, as they
are cut off by the forum.
r not
the case when a random unused variable is inserted in front of
it. (For reference I'm building the unittest using something
similar to `dub build --build=unittest --config=unittest --force
--archType=x86_64`, though the project is a library thus there
are some complications:
https://
I found a this thread about testing libraries:
https://forum.dlang.org/post/mailman.1807.1522279261.3374.digitalmars-d-le...@puremagic.com
But it's very old, yet I have the same issue today.
I want to build a unittest executable for the library I've made,
but given I'm trying to
Hello,
I'm trying to setup a minimal testing process with unittest.
However, I would like to run the tests of a single file to keep
things fast.
At the moment, it runs all unittests that are imported with a
file.
eg.
`rdmd -I... source/foo.d` will run unittests bar.d if it is
imported
(version 2)
// import x;
unittest {
// import pp: foo; // wrong name is accepted if x is imported
import p: foo;
foo;
}
```
Looks like <https://issues.dlang.org/show_bug.cgi?id=15086>.
On Saturday, 6 February 2021 at 14:52:57 UTC, Adam D. Ruppe wrote:
[...]
That one `import p;` is kinda weird, it should probably
complain then you imported one thing and got another, but
generally the name not matching is no problem at all.
```main.d (version 2)
// import x;
unittest
Module names and file names are completely independent on the
language level. You can have a file `whatever.d` with `module
foo.bar.totally.different;` and `import
foo.bar.totally.different` and it all works as long as you add
the whatever.d to the build.
The only reason people recommend they
```p.d
module pp;
void foo ()
{
import std.stdio: writeln;
__PRETTY_FUNCTION__.writeln;
}
```
```x.d
import p;
```
```main.d
import x;
unittest {
import pp: foo; // wrong name is accepted if x is imported
// import p: foo;
foo;
}
```
$ dmd -i -unittest -main -run main
void pp.foo
On 1/13/21 1:22 PM, apz28 wrote:
core.exception.InvalidMemoryOperationError@src\core\exception.d(647):
Invalid memory operation
I've struggled with this as well. It doesn't even tell you the original
usage point that causes the exception.
I believe stack traces are disabled from printing on
core.exception.InvalidMemoryOperationError@src\core\exception.d(647): Invalid
memory operation
reference D runtime unittest executor codes
try
{
fp();
++results.passed;
}
catch ( Throwable e )
{
import core.stdc.stdio
On Saturday, 12 December 2020 at 12:47:59 UTC, Tobias Pankrath
wrote:
On Saturday, 12 December 2020 at 12:18:47 UTC, Andre Pany wrote:
In any case you should have configurations in your dub json.
Thank you for your detailed reply and I am sure I can make it
work in the way you described.
B
On Saturday, 12 December 2020 at 12:18:47 UTC, Andre Pany wrote:
In any case you should have configurations in your dub json.
Thank you for your detailed reply and I am sure I can make it
work in the way you described.
But I don't think my use case is invalid and dub should improve
its usa
"dub" or "dub build", here you set
targetType library. The second configuration you name unittest,
you set targetType executable and you also have to set
attribute mainSourceFile. This configuration is used
automatically by command "dub test".
Kind regards
A
On Saturday, 12 December 2020 at 11:13:45 UTC, Tobias Pankrath
wrote:
Whenever I come back to some D, I seem to be stumbling over
dub. Somehow dub and I don't align:
$ dub init dubtest && cd dubtest
$ dub test
-> creates executable `dubtest` (saying Falling back to &
Whenever I come back to some D, I seem to be stumbling over dub.
Somehow dub and I don't align:
$ dub init dubtest && cd dubtest
$ dub test
-> creates executable `dubtest` (saying Falling back to "dub -b
unittest".)
$ touch source/lib.d
dub test
-> creates ex
plier`.
+/
int mul(int n)
{
return multiplier * n;
}
///
unittest
{
// Will end up in examples section, provided /// is
placed above unittest
Foo foo = new Foo;
foo.multiplier = 2;
int four = foo.mul(2);
int six = foo.mul(3);
On Monday, 26 October 2020 at 13:36:58 UTC, Steven Schveighoffer
wrote:
On 10/26/20 9:16 AM, Vladimirs Nordholm wrote:
[...]
Wherever you want. Generally people put it right after the
thing being tested to keep files organized.
When the compiler runs unittests it runs them all in the
seque
come from a background of having a completely separate tests folder
with only tests, so I do not know what the general best-practice is with
D. Where should the `unittest` code block go?
Wherever you want. Generally people put it right after the thing being
tested to keep files organized
separate tests
folder with only tests, so I do not know what the general
best-practice is with D. Where should the `unittest` code block
go?
On Thu, Aug 13, 2020 at 08:30:44AM +, Jonathan via Digitalmars-d-learn
wrote:
[...]
> Is there a reason you need to run all unittests every time you want to
> run the program?
During development, this is a valuable time-saver: instead of compiling
twice, once with -unittest and once w
On 8/13/20 5:02 AM, Nils Lankila wrote:
On Thursday, 13 August 2020 at 08:49:21 UTC, WebFreak001 wrote:
On Thursday, 13 August 2020 at 07:52:07 UTC, novice3 wrote:
Hello.
I don't use dub.
I use Windows and *.d file association to compile small apps by dmd
with "-i -unittest -g"
On Thursday, 13 August 2020 at 09:02:28 UTC, Nils Lankila wrote:
programmatically, in a way it is already, but by calling
function
Better with compiler switch, may be...
On Thursday, 13 August 2020 at 08:49:21 UTC, WebFreak001 wrote:
On Thursday, 13 August 2020 at 07:52:07 UTC, novice3 wrote:
Hello.
I don't use dub.
I use Windows and *.d file association to compile small apps
by dmd with "-i -unittest -g" switches.
Now i update dmd, and f
On Thursday, 13 August 2020 at 08:30:44 UTC, Jonathan wrote:
Is there a reason you need to run all unittests every time you
want to run the program?
Starting app with unittests while develop - frequent event for me.
Releasing app - rare event for me.
I want do frequent action without efforts (j
On Thursday, 13 August 2020 at 08:49:21 UTC, WebFreak001 wrote:
Try
version (unittest) extern(C) __gshared string[] rt_options =
["testmode=run-main" ];
Thanks! It works as needed.
1 - 100 of 453 matches
Mail list logo
