On 4/30/2014 4:17 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Wednesday, 30 April 2014 at 20:00:59 UTC, Russel Winder via
>
>> (*) Are we allowed to have gotos any more since Dijkstra's letter?
>
> You better ask the dining philosophers.

Nah, they're too busy trying to figure out how to use their forks.

On 4/30/2014 1:36 PM, Andrei Alexandrescu wrote:
> One good example is networking tests - if I worked on an airplane I'd love to
> not test tests that need connectivity with a simple regex.

I am suspicious that testing networks with a unit test is an inappropriate use of unit tests.

Unit tests should be testing individual functions. The "network" for those tests should be a mockup, not the actual network. A mock network:

1. can model extreme, unusual, perverse, and corner cases of networks, whereas real networks try to avoid that

2. will generate reproducible results


Testing networks should be more of a system test, not a unit test.

On Thursday, 1 May 2014 at 09:58:32 UTC, Jacob Carlborg wrote:
> On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
>
>> This cannot be a good idea. If the block says unittest then it contains
>> unit tests, not integration tests or system tests, just unit tests.
>
> Then we need to come up with a separate framework for doing all other kinds of tests.

This is why I started to learn Cucumber.

Atila

On Thursday, 1 May 2014 at 10:50:12 UTC, John Colvin wrote:
> On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
>> On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
>>> On 2014-04-30 11:43, Dicebot wrote:
>>>
>>>> This is common complaint I still fail to understand. I have never ever
>>>> wanted to run a single unit test, why would one need it? If running all
>>>> module tests at once creates problems than either module is too big or
>>>> unit tests are not really unit tests.
>>>
>>> Why would I run more tests than I have to?
>>
>> Because you hardly notice difference between 0.1 and 0.5 seconds
>
> The compilation time is often more of a problem than the runtime.

For me it's the output. I don't want to see the output of other
tests when I'm debugging a failure.

Atila

On 5/3/2014 3:32 PM, Walter Bright wrote:
> On 4/30/2014 1:36 PM, Andrei Alexandrescu wrote:
>> One good example is networking tests - if I worked on an airplane I'd
>> love to
>> not test tests that need connectivity with a simple regex.
>
> I am suspicious that testing networks with a unit test is an
> inappropriate use of unit tests.
>
> Unit tests should be testing individual functions. The "network" for
> those tests should be a mockup, not the actual network. A mock network:
>
> 1. can model extreme, unusual, perverse, and corner cases of networks,
> whereas real networks try to avoid that
>
> 2. will generate reproducible results
>
>
> Testing networks should be more of a system test, not a unit test.
>

I'm not sure mock networks can really be used for testing a client-only lib of some specific protocol. There may also be other examples.

There's also the question of whether or not D's "unittest {...}" should *expect* to be limited to tests that are *technically* "unit tests". Currently, "unittest {...}" is useful for more forms of testing than just "unit" tests. I think it's debatable whether we want kill off those uses without offering a comparable alternative with reasonable migration.

On 5/3/2014 6:57 PM, Nick Sabalausky wrote:
> I'm not sure mock networks can really be used for testing a client-only lib of
> some specific protocol. There may also be other examples.
>
> There's also the question of whether or not D's "unittest {...}" should *expect*
> to be limited to tests that are *technically* "unit tests". Currently, "unittest
> {...}" is useful for more forms of testing than just "unit" tests. I think it's
> debatable whether we want kill off those uses without offering a comparable
> alternative with reasonable migration.


I'm not suggesting killing off anything. I'm suggesting it may not be good practice to use unit tests for testing actual networks.

On Sat, 03 May 2014 19:36:53 -0700
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 5/3/2014 6:57 PM, Nick Sabalausky wrote:
> > I'm not sure mock networks can really be used for testing a client-only lib of some specific protocol. There may also be other examples.
> >
> > There's also the question of whether or not D's "unittest {...}" should *expect* to be limited to tests that are *technically* "unit tests". Currently, "unittest {...}" is useful for more forms of testing than just "unit" tests. I think it's debatable whether we want kill off those uses without offering a comparable alternative with reasonable migration.
>
> I'm not suggesting killing off anything. I'm suggesting it may not be good practice to use unit tests for testing actual networks.

I'd write unit tests which talked to sockets on the same computer if that was what was required to test a particular function, but I would definitely consider it bad practice to have a unit test try to talk to anything on a separate computer. Now, if you're using unittest blocks for something other than unit tests, then I guess that that could be fine, though I question that it's good practice to use unittest blocks for other purposes.

Regardless, unittest blocks don't really put any restrictions on what kind of code can go in them, and I'd prefer that that stay the case. The discussion on parallelizing unit tests threatens that on some level, but as long as we have the means to mark unittest blocks in some manner that tells the test runner not to run them in parallel with any other unittest blocks, then I think that we should be fine on that front.

- Jonathan M Davis

On Wednesday, 30 April 2014 at 04:22:52 UTC, Rikki Cattermole wrote:
> It may be a good time to repeat, we need a marketing manager for D!
> Somebody really really needs to focus on getting us out there.

If somebody has some time, they could post a solution in D to this problem:

http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language

It all helps to get the language visible.

Danny Weldon:

> If somebody has some time, they could post a solution in D to this problem:
>
> http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language
>
> It all helps to get the language visible.

Here are my solutions:
http://forum.dlang.org/thread/pvojsrqmaksqwokuekhk@forum.dlang.org

I don't have a Stackexchange account. You are welcome to post the two solutions (of two different problems).

Bye,
bearophile

On 2014-05-03 21:52, Atila Neves wrote:

> For me it's the output. I don't want to see the output of other
> tests when I'm debugging a failure.

That's a good point.

-- 
/Jacob Carlborg