On Wednesday, 19 June 2013 at 11:01:05 UTC, Szymon Gatner wrote:
> This is not strictly D related but I am very curious about D's community opinion on the points made by non other than Jim Coplien here:
>
> http://www.tele-task.de/archive/video/flash/16130/
>
> D is the only language (that I am aware of) that has first class unit testing support. What do you think? Do we really just "mentally masturbate"?
>
> Article about the myths of TDD referenced in the talk:
>
> http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1027&context=csse_fac

From experience, unitests are various return depending on the code. Some code is easily testable and the ROI is high, some code is just hard to automatically test.

On the code that is unittest compliant, I notice a very low number of bugs (actually close to 0 defect) when I do proper unittesting. Sadly, all code isn't like that.

On Wed, 19 Jun 2013 16:34:03 +0100, Szymon Gatner <noemail@gmail.com> wrote:

> On Wednesday, 19 June 2013 at 14:04:35 UTC, Regan Heath wrote:
>> On Wed, 19 Jun 2013 12:01:02 +0100, Szymon Gatner <noemail@gmail.com> wrote:
>>> D is the only language (that I am aware of) that has first class unit testing support. What do you think? Do we really just "mentally masturbate"?
>>
>> I'm more interested in whether DCI is doable/natural in D.. that seems like an interesting idea.
>>
>> R
>
> I actually learned about DCI from that very presentation and am
> wondering the same thing.

So.. to me it seems the basic idea is that you have your object i.e. BankAccount which is a dumb/data object with few methods (perhaps just properties).  Then, depending on the use-case it participates in, it takes on a role (at run time) which carries with it some methods.

So.. something like?

import std.stdio;

// Dumb/data object
class BankAccount
{
public:
  string name;
  int balance;

  this(string _name, int _balance)
  {
    name = _name;
    balance = _balance;
  }
}

// Roles..
class SourceAccount(T)
{
private:
  T account;

public:
  alias account this;

  this(T _account)
  {
    account = _account;
  }

  void TransferTo(TargetAccount!BankAccount target, int amount)
  {
    target.balance += amount;
    balance -= amount;
  }
}

class TargetAccount(T)
{
private:
  T account;

public:
  alias account this;

  this(T _account)
  {
    account = _account;
  }
}

// Use case..
void TransferFunds(BankAccount sa, BankAccount ta, int amount)
{
  auto source = new SourceAccount!BankAccount(sa);
  auto target = new TargetAccount!BankAccount(ta);
  source.TransferTo(target, amount);
}

// Logic..
void main()
{
  auto savings = new BankAccount("savings", 10000);
  auto current = new BankAccount("current", 250);
	
  writefln("Current balances: ");
  writefln("  %s: %d", savings.name, savings.balance);
  writefln("  %s: %d", current.name, current.balance);
	
  writefln("");
  writefln("Transfer funds..");
  TransferFunds(savings, current, 500);
	
  writefln("");
  writefln("New balances: ");
  writefln("  %s: %d", savings.name, savings.balance);
  writefln("  %s: %d", current.name, current.balance);
}

R
-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wednesday, 19 June 2013 at 11:01:05 UTC, Szymon Gatner wrote:
> This is not strictly D related but I am very curious about D's community opinion on the points made by non other than Jim Coplien here:
>
> http://www.tele-task.de/archive/video/flash/16130/
>
> D is the only language (that I am aware of) that has first class unit testing support. What do you think? Do we really just "mentally masturbate"?
>
> Article about the myths of TDD referenced in the talk:
>
> http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1027&context=csse_fac

If you could point to the time where he talks about TDD that would be good.

Based on what I've be hearing is his biggest complaint is about classes and class hierarchy design. From this I'm pretty sure this is where he takes issue with TDD, it doesn't help build good class design.

At about 1:09 he goes into talking about roles, specifically, write a script then assign out the role to a class to perform that role. And in this way, it sounds very much like test driven design. Script the action, find/build/train those to fulfill those actions, he just left out the testing part.

For my hobby projects I find it very hard to find a use for Objects and their hierarchy, I find structures and functions are much easier to deal with and test (not that I do the best on testing).

On Wed, Jun 19, 2013 at 04:52:22PM +0200, bearophile wrote:
> irritate:
> 
> >My feelings about TDD changed when I saw that talk explaining TDD in the context of double-entry bookkeeping in accounting
> 
> I think the usefulness of the TDD method is greatly different for different kinds of code to write.
> 
> This is another data point for the discussion: http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/
[...]

As someone else has pointed out, we need to distinguish between unit-testing and TDD.

I love D's built-in unittests. They have singlehandedly improved the quality of my code by leaps and bounds, just because they're so convenient to use, and help catch careless mistakes early.

However, I am skeptical about TDD.  Ideally, what unittests *really* should be used for, is to set expectations about what results a piece of code should give, but *how* that code achieves said result is a major question that's never adequately addressed by TDD.  Using the above sudoku example (thanks, bearophile!), one can write a unittest that verifies a sudoku solution, but that in itself says *nothing* about how the code should go about deriving such a solution.  Producing "minimal code" that satisfies the test simply gets you stuck in local minima without ever getting any nearer an actual solution for the problem.

Before methodologies like TDD could even begin to work, one has to *solve* the problem at hand first -- analyse the problem, explore its structure, invent an algorithm, then one can verify the correctness of one's implementation with unittests. You have to already have an idea about how things are going to work, before TDD can help you.

Of course, for trivial everyday problems like sorting and manipulating lists of stuff, moving numbers around, etc., TDD can certainly work well -- because the underlying algorithms are so trivial that there's not much need to actually do any algorithm design. In such cases, "minimal code" is pretty close to "actual solution", so TDD converges on it pretty quickly. For algorithmically hard problems, however, like solving sudoku, or computing n-dimensional convex hulls, or writing a compiler optimizer, TDD simply falls flat on its face because it doesn't even begin to address fundamental issues of how one achieves the desired results from the inputs in the first place.


T

-- 
Без труда не выловишь и рыбку из пруда.

Am 19.06.2013 17:54, schrieb Jacob Carlborg:
> On 2013-06-19 14:08, Paulo Pinto wrote:
>
>> Additionally I am yet to find any form of unit testing that is possible
>> to apply to UI code, in a way that the ROI really pays off.
>
> At work we use RSpec together with Capybara to test the UI, or rather
> the full stack. That is, for our web site. Capybara is used, via
> different drivers, to control the web browser. When writing the test you
> can use a driver that opens the web browser and you can actually see it
> clicking on buttons, filling in forms and so on. When running the tests
> in a CI server we use a faster headless web browser.
>

With browser UI testing is a bit easier, but what do you do when doing native applications?

Or to come back to the browser area, you need to test the UI in all target browsers, across all supported OS. Not all tools do this, even
Selenium, which I have in high regard, has issues.

--
Paulo

Am 19.06.2013 17:32, schrieb Szymon Gatner:
> On Wednesday, 19 June 2013 at 14:44:26 UTC, irritate wrote:
>> On Wednesday, 19 June 2013 at 11:01:05 UTC, Szymon Gatner wrote:
>>> D is the only language (that I am aware of) that has first class unit
>>> testing support. What do you think? Do we really just "mentally
>>> masturbate"?
>>
>> My feelings about TDD changed when I saw that talk explaining TDD
>> in the context of double-entry bookkeeping in accounting (maybe
>> linked off of here:
>> http://unhandled-exceptions.com/blog/index.php/2009/02/15/uncle-bob-tdd-as-double-entry-bookkeeping/).
>>
>>
>> Writing your tests and code separately is actually an important
>> part of it.  If you are copy-pasting your code into your test
>> after you write it, then that's not really giving you the
>> guarantees you want.
>>
>> And for anyone who's never tried the loop of:
>> 1. Write a failing test.
>> 2. Write the code that makes the test pass.
>> 3. Make all the lights go green, then goto 1.
>>
>> You might want to give it a try.  I was surprised by the feeling
>> of accomplishment I would get from making the failing tests pass.
>>
>> irritate
>
>
> That is actually the way I do TDD too. In fact, doing it any
> other way is actually against 3 laws of TDD:
>
> http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
>
> and is plain wrong. Writing tests for working (legacy) code will
> not in any way shape it's structure and often results in useless
> tests. TDD is a design technique not a testing technique.
>
> I am pretty sure that many people will agree that TDD works, I
> was actually curious on opinion on the presentation which claims
> that TDD does not work at all and is in fact total BS.

How do you TDD:

- native application UI code
- embedded native code
- distributed algorithms
- applications done in native languages with third party libraries only available in binary form
- GPGPU code

Any of those cases full new greenfield applications.

--
Paulo

Start at about 23 min. Key phrase at about 29 min.

I completely agree with, "we right tests because we don't understand our code." We don't want to understand all the code, we also couldn't possibly achieve perfect understanding anyway, so let us make the burden of transferring that knowledge easier by having tests which catch mistakes.

I think his school analogy is wrong. TDD is more like teachers writing a test to define what a successful teaching would be, then developing a course which produces those results. Then you administer the test to make sure your teaching fulfilled the requirement. Oh that is exactly what we do.

On Wednesday, June 19, 2013 10:29:49 H. S. Teoh wrote:
> On Wed, Jun 19, 2013 at 04:52:22PM +0200, bearophile wrote:
> > irritate:
> > >My feelings about TDD changed when I saw that talk explaining TDD in the context of double-entry bookkeeping in accounting
> > 
> > I think the usefulness of the TDD method is greatly different for different kinds of code to write.
> > 
> > This is another data point for the discussion: http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/
> 
> [...]
> 
> As someone else has pointed out, we need to distinguish between unit-testing and TDD.
> 
> I love D's built-in unittests. They have singlehandedly improved the quality of my code by leaps and bounds, just because they're so convenient to use, and help catch careless mistakes early.
> 
> However, I am skeptical about TDD.

Exactly. With TDD, you write the tests and then write the code, and I personally don't like that approach at all. I write the code; then I write the tests; and then I work on both until the code works with a reasonable amount of testing (which in most cases, I think is 100% with lots of corner cases being tested, but there's plenty of code where you can't reasonably do that). And while that approach involves heavy unit testing, it's not "test-driven" at all.

But if you want to do TDD, D certainly allows it. The unit testing facilities in the language enable unit testing, but how you go about writing them is completely up to you.

- Jonathan M Davis

On 2013-06-19 19:47, Paulo Pinto wrote:

> With browser UI testing is a bit easier, but what do you do when doing
> native applications?

I haven't done any testing of the UI in native applications. It was quite a while since I worked on a native application with a GUI. For CLI based tools I use similar tools, Cucumber (I could use RSpec instead) and Aruba.

> Or to come back to the browser area, you need to test the UI in all
> target browsers, across all supported OS. Not all tools do this, even
> Selenium, which I have in high regard, has issues.

Yes, absolutely. We currently don't do that. But it at least better to test in one browser than no one.

There's a testing service, sauce labs, that supports many web browser. I haven't used it myself.

https://saucelabs.com/

-- 
/Jacob Carlborg

On 2013-06-19 19:29, H. S. Teoh wrote:

> Producing "minimal
> code" that satisfies the test simply gets you stuck in local minima
> without ever getting any nearer an actual solution for the problem.

Then your test doesn't cover enough cases.

> Before methodologies like TDD could even begin to work, one has to
> *solve* the problem at hand first -- analyse the problem, explore its
> structure, invent an algorithm, then one can verify the correctness of
> one's implementation with unittests. You have to already have an idea
> about how things are going to work, before TDD can help you.

I agree. I haven't watch the video(s) but I think TDD is for testing an implementation not a design.

Sometimes you can also test the design, or rather find wholes in the design.

-- 
/Jacob Carlborg