"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3F226F64.EC1B9CCC@chello.at...
> Thank you for these hints. They may or may not be sufficient.
>
> The problem is that unittests are implemented on top of almost any programming language. Most of the time they are separate testing frameworks.
>
> The D claim to support unittests would make a lot of sense if - and only if - the support is out of the box. Otherwise it means nothing.
>
> I'll try to build on the hooks you gave me, but it will only make sense when reintegrated into D.

Let me know how it goes. -Walter

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bfn8lg$2hm2$1@digitaldaemon.com...
> > It does already, with the file/line of the failed contract. Of course,
you
> > can put any code you want in the unittest blocks, not just assert()'s.
>     It isn't enough for a couple of reasons: assert just give me the
> file/line of the assert failed, not the call stack. If I have a contract
> failing inside a method after twenty calls from my unittest the error
> message don't give me any context to work with. A very good solution would
> be making the contract failure info Eiffel-like, dumping the call stack
and
> the variables in stack at the time (so we can figure out the context). The current state is really crude, I usually resort to insert several lines of printf to pinpoint the error. Of course I could debug instead of this, but
I
> use TDD and in any other language the tests are enough.

The stack trace is a good idea. I use it regularly in a debugger, which prints it out just fine. I've thought of some ways to implement it in general for D exceptions, which would solve your issue.


>     Today we have units of unittests so I think each unit would be
> independent. If I have three "unittest" blocks they are independent (they
> are test fixtures, and each must be independent). When I change something
> it's important to know that the "insert" operation failed but everything
> else is still fine. Today it's all or nothing.

You can continue by wrapping the tests you want to continue with a try-catch.


>     If unittests had names (like "unittest testFindString { ... }") using
> reflective libraries we could automate this process and create different
> test reporters for different environments (e.g. text, GUI, XML, etc.) like
> any of the xUnit tools make. Walter, how much do you know about the xUnit
> tools (e.g. jUnit, sUnit)?

Nothing.

> There's a lot of info in www.junit.org about how
> they could develop a powerful, extensible, tool using Java's reflexive
> mechanisms. I'll make a summary of jUnit basic features:
>
> - It has classes representing test cases, test suites, test results and
test
> runners.
> - Test cases are just classes extending TestCase containing methods named
> testXXXXXXXX and two special methods: setUp and tearDown. When the test
case
> is executed the test runner uses reflection to find all methods named testXXXXXX, and for each one executes the TestCase setUp method, the
current
> test method and finally calls the TestCase tearDown method. If an
assertion
> fails inside a TestCase test method, it raises an exception that is used
to
> report the failure.
> - TestSuites are a bunch of TestCases bundled together.
> - TestResults encapsulate the details of the executed tests, including
which
> failed, which succeded and which raised uncatched exceptions.
> - TestRunners run the tests and report the failures in a given medium
(e.g.
> text, GUI, XML, e-mail to the developers, etc.).
>
>    This is just a quick look of how it works, but almost every programmer
> coming to D will look after these features. I use jUnit all the time in
> Java, and D unittest support is pale in comparison. If we need some kind
of
> house-keeping operations (i.e. setUp and tearDown) we have to remember
> calling them explicitly, if we need some kind of alternative medium (GUI
is
> much better than text) we must explicit code each every time. I'm tempted
to
> rewrite jUnit in D, actually I'm doing that right now, just to have these features.

Sounds like a good idea. Such a "dUnit" be a great tool to add. Keep us posted on the progress on it!

Hi,

    Comments embedded.

"Walter" <walter@digitalmars.com> escreveu na mensagem
news:bhbk0a$1p9k$1@digitaldaemon.com...
[snip]
> The stack trace is a good idea. I use it regularly in a debugger, which prints it out just fine. I've thought of some ways to implement it in general for D exceptions, which would solve your issue.

    Great! It's one of the most annying things today.

> >     Today we have units of unittests so I think each unit would be
> > independent. If I have three "unittest" blocks they are independent
(they
> > are test fixtures, and each must be independent). When I change
something
> > it's important to know that the "insert" operation failed but everything else is still fine. Today it's all or nothing.
>
> You can continue by wrapping the tests you want to continue with a try-catch.

    I guess this is a matter of personal taste. I usually write orthogonal
tests, so a failure in one doesn't imply in failures of others. The xUnit
tools use this metaphor too, and many programmers use it, but I don't need
it this way.

> >     If unittests had names (like "unittest testFindString { ... }")
using
> > reflective libraries we could automate this process and create different test reporters for different environments (e.g. text, GUI, XML, etc.)
like
> > any of the xUnit tools make. Walter, how much do you know about the
xUnit
> > tools (e.g. jUnit, sUnit)?
>
> Nothing.

    I think it'll be very good for you to read papers and code about these
tools. They'll give you some perspective of the "standards" in unit testing.

> > There's a lot of info in www.junit.org about how
> > they could develop a powerful, extensible, tool using Java's reflexive
> > mechanisms. I'll make a summary of jUnit basic features:
> >
> > - It has classes representing test cases, test suites, test results and
> test
> > runners.
> > - Test cases are just classes extending TestCase containing methods
named
> > testXXXXXXXX and two special methods: setUp and tearDown. When the test
> case
> > is executed the test runner uses reflection to find all methods named testXXXXXX, and for each one executes the TestCase setUp method, the
> current
> > test method and finally calls the TestCase tearDown method. If an
> assertion
> > fails inside a TestCase test method, it raises an exception that is used
> to
> > report the failure.
> > - TestSuites are a bunch of TestCases bundled together.
> > - TestResults encapsulate the details of the executed tests, including
> which
> > failed, which succeded and which raised uncatched exceptions.
> > - TestRunners run the tests and report the failures in a given medium
> (e.g.
> > text, GUI, XML, e-mail to the developers, etc.).
> >
> >    This is just a quick look of how it works, but almost every
programmer
> > coming to D will look after these features. I use jUnit all the time in Java, and D unittest support is pale in comparison. If we need some kind
> of
> > house-keeping operations (i.e. setUp and tearDown) we have to remember
> > calling them explicitly, if we need some kind of alternative medium (GUI
> is
> > much better than text) we must explicit code each every time. I'm
tempted
> to
> > rewrite jUnit in D, actually I'm doing that right now, just to have
these
> > features.
>
> Sounds like a good idea. Such a "dUnit" be a great tool to add. Keep us posted on the progress on it!

    Looks like this week I'll resume coding in D, but most of the dUnit tool
depends on the stack trace information.

    Best regards,
    Daniel Yokomiso.

"I drink to make other people interesting."
 - Groucho Marx



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 14/8/2003