Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unittest hygeine - version(VibeUnittest) #673

Open
Abscissa opened this issue May 25, 2014 · 6 comments
Open

Unittest hygeine - version(VibeUnittest) #673

Abscissa opened this issue May 25, 2014 · 6 comments

Comments

@Abscissa
Copy link

Currently, projects using vibe.d cannot run their own unittests without also running vibe's unittests, unless they manually provide their own test runner (which is awkward and obscure).

A common and more hygienic idiom is for a library to wrap its own unittests in a lib-specific special version block. Accordingly, Vibe'd unittests should change from:

unittest
{
...
}

to:

version(VibeUnittest) unittest
{
...
}

As one effect of vibe's current behavior, running the unittests in a program which uses both vibe and mysql-native results in a numerically-named file being created in the current directory, containing something like this:

<143>1 0000-01-01T00:00:00.000001 - appname - - - αβγ
<142>1 0000-01-01T00:00:00.000001 - appname - - - αβγ
<141>1 0000-01-01T00:00:00.000001 - appname - - - αβγ
<140>1 0000-01-01T00:00:00.000001 - appname - - - αβγ
<139>1 0000-01-01T00:00:00.000001 - appname - - - αβγ
<138>1 0000-01-01T00:00:00.000001 - appname - - - αβγ
<137>1 0000-01-01T00:00:00.000001 - appname - - - αβγ
@s-ludwig
Copy link
Member

At least if you use DUB to build (without --rdmd or --combined), it should only run the unit tests of the top level package. My feeling is that requiring every library to use such version hacks is the wrong way to go about it. It would be much better if either the language, the unit test runner, or the build tool solves this without additional work for each library.

@Abscissa
Copy link
Author

I agree it's less than ideal, but when I brought it up on the NG some
months back there wasn't any interest in fixing it, so this is just how
it is D for the forseeable future.

@s-ludwig
Copy link
Member

What I'm currently thinking about is letting DUB automatically define something like Root_vibe_d, analogous to Have_vibe_d, so that this can be used here (although it needs a better prefix, and maybe a more D-like naming convention, such as RootVibeD).

@mihails-strasuns
Copy link
Contributor

Currently, projects using vibe.d cannot run their own unittests without also running vibe's unittests

I believe it is a good default and would prefer it to stay that way.

@mihails-strasuns
Copy link
Contributor

(assuming rdmd, not a custom build tool)

@Abscissa
Copy link
Author

At the very LEAST, can we at least get vibe's unittests to quit spamming stdout and the filesystem's current working directory?

s-ludwig added a commit that referenced this issue Sep 10, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants