On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:
This hypotetical unittest is testing a hypotetical class in a
hypotetical module with hypotetical properties.
Why is it outside the class? I don't know, maybe it needs
access to two classes which are defined in thesame module. But
also out of personal preference, I don't like random unittest
declarations inside my class. Regardless, I think it's
important for unittests to be able to do this.
Fair enough. That is a reasonable position, I guess.
OK. So let's say, that the class-oriented programmer is now
required to use one-class-per-module in D (in order to ensure the
encaspulated private parts of the object are not penetrated by
its neigbours in the module) - i.e the solution that most here
seem to be suggesting.
Now, lets say that programmers wants to put in a unittest, in the
same module (but outside the class - as you've suggested).
Let's also say, the programmer does *not* want the unittest to be
able to penetrate the private parts of the class.
If human error creeps in to their unittest, as it inevitably
will, then they will not know about this until runtime. How do
they get around this problem? I guess, they'll be forced to put
the unittest inside the class. But what if, like you, they don't
want to?
Something like this below, would actually enhance the value of
unittests too, because now the compiler would require your
unittest to use the objects public interface (human error cannot
creep in now - and people like me won't have to inspect every
unittest to see that its programming to the interface):
---------------------
module test;
@safeinterface class Dog
{
private string noiseType;
public string makeNoise()
{
this.noiseType = "woof";
return this.noiseType;
}
}
unittest
{
Dog d = new Dog();
d.noiseType = "meow"; // ohhps. human error - lucky I used
@safeinterface
// compiler will statically enforce
this.
}
--------------
