ScalaDBTest 0.1

[Ken Egervari]

Hi guys,

I wrote a framework that intends to replace DBUnit. It promises a 30%
reduction in the number of characters used compared to dbunit, and
mass simplifications and extra features across the board.

It's on git. You can read about it there:
http://github.com/egervari/scaladbtest

I only spent 2 or 3 days on it so far, but all the basic functionality
is there and it works with mysql and hsqldb for sure. I even have it
working on a real project that has 1093 tests and hundreds of records
of test data, so it's field tested ;) It actually runs faster than
dbunit too by about 10 seconds :)

Enjoy,

Ken

[Thomas Jung]

Hi Ken,

How do you use DBUnit or ScalaDBTest without introducing redundancy
all over the place?

The knowledge about the data is in the files and to some extend in
your tests as well.
For example from your test suite:

tester.onBefore("two_string_table.dbt")
jdbcTemplate.queryForInt("select count(*) from two_string_table")
should equal (2)

Thomas

[Ken Egervari]

That test is just to verify that scaladbtest did in fact insert the
rows in the database. It's testing to make it is doing what it's
supposed to do ;)

As an application developer, you will not have to assert that
scaladbtest has loaded your data - you can just make it use of it when
your test starts.

Does that answer your question?

On Oct 22, 10:05 am, Thomas Jung <thomas.andreas.j...@googlemail.com>
wrote:

[Thomas Jung]

What I meant is that the tests you write have to have some knowledge
about the data in the database. (should equal (2) in the example.)

If you have a configuration like:

country:
- id: 1, name: "Canada"

how do you check that the software under test loads it correctly
without repeating the data in your tests?

I found an old article about dbunit http://onjava.com/pub/a/onjava/2004/01/21/dbunit.html
with this example.

<?xml version='1.0' encoding='UTF-8'?>
<dataset>
<EMPLOYEE employee_uid='1'
start_date='2001-01-01'
first_name='Drew' ssn='333-29-9999'
last_name='Smith' />
<EMPLOYEE employee_uid='2'
start_date='2002-04-04'
first_name='Nick' ssn='222-90-1111'
last_name='Marquiss' />
<EMPLOYEE employee_uid='3'
start_date='2003-06-03'
first_name='Jose' ssn='111-67-2222'
last_name='Whitson' />
</dataset>

public void testFindBySSN() throws Exception{

EmployeeFacade facade = //obtain somehow

EmployeeValueObject vo =
facade.getEmployeeBySocialSecNum("333-29-9999");

TestCase.assertNotNull("vo shouldn't be null", vo);
TestCase.assertEquals("should be Drew",
"Drew", vo.getFirstName());
TestCase.assertEquals("should be Smith",
"Smith", vo.getLastName());
}

One way around this problem would be to copy the actual result in an
IDataSet compare it to a expected IDataSet that is loaded from a
distinct file. (The ids would still be redundant.) The problem with
this approach is the overhead to copy the data (correctly),
maintaining an additional set of expected result files and that the
test is less readable.

Do you have a solution for this problem?

Thomas

[Ken Egervari]

Yes, I do (hopefully).

It's not implemented yet, but it's next on the list, and it shouldn't
be too difficult. Perhaps I'll run the idea by you and you can let me
know if this fixes it for you.

The framework already has a way to specify labels, so you can label a
record like this:

country:
- [Canada] country_id: 1, name: "Canada"
- [United States] country_id: 2, name: "United States"

Of course, there's some redundancy there, so you can pass in an
expression to the name property like this:

country:
- [Canada] country_id: 1, name: $label
- [United States] country_id: 2, name: $label

That gets rid of the duplication in text whenever it's needed, but we
still have the duplication where name=$label, so we can use default
values to refactor that.

country:
? name: $label
- [Canada] country_id: 1
- [United States] country_id: 2

So far, everything has been implemented as shown. The next steps have
not, but will be.

I agree that ids are a messy way to reference data that leaves a lot
to be desired. One thing we can do is get the framework to generate
the ids... that way we can access the rows from labels instead:

country: [pk: country_id]
? name: $label
- [Canada]
- [United States]

This doesn't work for pk's consisting for of two or more columns, but
it's going to work in 99% of cases where you are pulling a root object
that is needed for test against.

Now, one thing I've left out is a name space for the label. It's
implied because of the table name. The reason it's important for
references later. The syntax could look something like this:

province: [pk: province_id]
- name: $label
- [Ontario] province_id: $country(Canada)
- [New York] province_id: $country(United States)

I haven't really decided yet yet to put these in quotes or notes. I'll
have to see what feels natural and looks best. Maybe this looks
better?:

province: [pk: province_id]
- name: $label
- ["Ontario"] province_id: $country("Canada")
- ["New York"] province_id: $country("United States")

Anyway, in your test code, you could do something like this:

val province = provinceDao.find( "Ontario".toId )

"toId" could be an implicit that maps Strings (or Symbols I guess) to
a wrapper that has a toId() method. The implicit will return the same
id that the framework generated when it parsed in all the test data.

Does this approach solve the problem? Suggestions/improvements?

[Ken Egervari]

Oh, it had occured to me that you probably don't even need the
namespacing. So something like

$label(Canada)

or

$label("Canada")

would work instead. See I'm still thinking it out ;)

[Dan Haywood]

If you want some inspiration on how to remove duplication in data
fixtures, take a look at Nat Pryce's make-it-easy library up on
googlecode. Would be very interested to see those ideas expressed in
Scala, with or without db support.

Dan

[Liam Knox]

what does 30% reductions in characters mean and how does this equate to time or money ?

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Kevin Wright]

It equates to 30% less time spent tracking down bugs in code that now doesn't even exist, and the money paid to the developer who does so.

--
Kevin Wright

mail / gtalk / msn : kev.lee...@gmail.com

pulse / skype: kev.lee.wright
twitter: @thecoda

[Liam Knox]

Really? You can accurately equate Characters to that ?  Where is Perl going Wrong?

[Kevin Wright]

PERL isn't going wrong, it's arguably the single best tool available in the extracting-and-reporting domain (the name's a bit of a give-away).  If you want to push the boundaries of the language then just be thankful that you can, and don't go crying to the original designers for failing to coddle you enough.

Sure, PERL is prone to obfuscation, it's even easy to abuse.  Then again, so are machetes, but I haven't seeing the campaigns for blunter knives yet...

And yes, there have been several case studies that show the number of bugs in a piece of code is basically a fixed percentage of the number of tokens, regardless of the language.  Fewer tokens = Fewer bugs.

[Liam Knox]

I think you are completely nuts. As soon as you start to declare this type of  idiocy about less characters more understandability, expressiveness etc, etc. Please study Kanji for a few years.

[Cédric Beust ♔]

On Sun, Oct 24, 2010 at 7:28 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

It equates to 30% less time spent tracking down bugs in code that now doesn't even exist, and the money paid to the developer who does so.

Sorry, but shorter code doesn't always equal "less bugs", I'm not sure where you got that idea from.

--
Cédric

[Kevin Wright]

It's just plain common sense, try it as a thought experiment:

You have a list of numbers representing amounts of some currency, and you need to add 20% to each number as a tax calculation.  You have two possible solutions:

1. low-level language, requiring 30 lines of code

2. high-level language, requiring 1 line of code

Which of these two solutions is most at risk of you introducing a bug?

[Cédric Beust ♔]

How about running this thought experiment on two high level languages, one which requires 3 lines of code and one which requires 1?

The answer is much less clear cut in this case.

The fact that you think in absolutes for problems as complex as this one is baffling (I wanted to say "nuts" but Liam already used that adjective :-)) but again, you are just trying to use oblique arguments to push Scala, although at least you refrained from naming the language this time around.

-- 

Cédric

Cédric

[Josh Berry]

2010/10/24 Cédric Beust ♔ <ced...@beust.com>:

> How about running this thought experiment on two high level languages, one
> which requires 3 lines of code and one which requires 1?
> The answer is much less clear cut in this case.

You can do the exact same thought experiment completely in Java.
Which is more likely to get wrong, the for/each loop, or a traditional
for loop? :)

Does this mean that one is perfect? Of course not. Errors can always exist.

[Kevin Wright]

Exactly... shorter is safer, compare:

Assembly - Many lines, almost any error can occur, including a seg fault and/or memory leak

Old Java - 5 lines, possible off-by-one error

New Java - 4 lines, off-by-one is no longer possible

Haskell - 1 (short) line - also removes the risk of NullPointerException and ConcurrentModificationException

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Liam Knox]

Absolute and complete crap.  I have never heard so much nonsense in all my life.  You cannot equate pure metrics like number of characters directly to something like 'understandability'.  When Microsoft had a concept of this == null.  Doesn't take many characters but what the hell does it mean?  Here you have a nothing argument

[Miroslav Pokorny]

@Kevin

I guess refactoring code so all identifiers are really short single characters ( a human powered obfuscator) means i just made my code have less bugs..right ?

If my class names are shorter and thus my source files have less characters does that mean my code has less bugs ?

if my code has no comments does that mean it has less bugs ?

[Kevin Wright]

No, I never stated that, because I don't believe it.

Using higher-level concepts with fewer *tokens* will reduce the number of bugs.  It just so happens that few tokens usually result in shorter code.

I don't even consider comments when thinking about how long code is, because comments aren't code.

Using shorter identifiers *may* reduce the risk of bugs if they're otherwise so long that they obscure the essential complexity of an algorithm.  Seriously, would you write something like this?

for(int indexOfAuthorInCurrentIteration=0; indexOfAuthorInCurrentIteration<=authorsFromNameQuery.length; ++indexOfAuthorInCurrentIteration) {

  Author currentAuthorBeingIteratedOver = authorsFromNameQuery[indexOfAuthorInCurrentIteration]

  // do something with the author

}

Do you NOT believe that shorter names would make the example clearer?

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Liam Knox]

You should code in A+ , I am sure you would love it 

[Miroslav Pokorny]

On Mon, Oct 25, 2010 at 7:04 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

No, I never stated that, because I don't believe it.

Using higher-level concepts with fewer *tokens* will reduce the number of bugs.  It just so happens that few tokens usually result in shorter code.

Thats not what you said, you made a generalised sweeping statement that can only be wrong because nothing in software is ever that simple.
 

--
mP

[Ricky Clarkson]

Fewer lines, all else being equal, will on average lead to fewer bugs.
Programming is largely about reading, and the larger the code the
harder it is to spot a logic error. I'm not advocating Perl-like
obfuscation ($_ anyone?), removing identifiers that have meaning, but
instead advocating removal of boilerplate, and identifiers that have
no meaning.

In a related topic, sometimes I find myself shortening code so that I
can see the bugs more clearly. I find it very effective.

[Liam Knox]

But there is so much more to all of this than something a banal as attributing it to numbers of characters.  For example levels of abstraction within a method, naming, method size etc, etc, etc.  I just can't understand why people simply bound around these pointless conjectures and random percentages figures.

[Kevin Wright]

On 25 October 2010 12:28, Miroslav Pokorny <miroslav...@gmail.com> wrote:

On Mon, Oct 25, 2010 at 7:04 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

No, I never stated that, because I don't believe it.

Using higher-level concepts with fewer *tokens* will reduce the number of bugs.  It just so happens that few tokens usually result in shorter code.

Thats not what you said

Wow, is it pantomime season already?  The only possible response is "oh yes I did"

I can even quote, from 11 emails ago:

"...several case studies that show the number of bugs in a piece of code is basically a fixed percentage of the number of tokens..."

 

you made a generalised sweeping statement that can only be wrong because nothing in software is ever that simple.

That itself is a generalised sweeping statement!

It can *only* be wrong, so it can never be right?  Did you truly mean to state that shorter code can *never* have fewer bugs than equivalent longer code?

[Ricky Clarkson]

My guess is the original poster also meant 'all else being equal', not
'if I remove levels of abstraction'.

[Kevin Wright]

I think it's fair to say that someone wouldn't go advertising a reduction in code size based on shorter identifiers and deleted comments :)

Which only leaves a higher level of abstraction as the means of achieving said reduction!

[Augusto Sellhorn]

This is really bizarre, I've heard people say that fewer lines of code
is desirable, but this is the first time I hear somebody say that X%
fewer characters lead almost exactly to X% reduction in complexity!

---------------

for(int
indexOfAuthorInCurrentIteration=0;
indexOfAuthorInCurrentIteration<=authorsFromNameQuery.length;
++indexOfAuthorInCurrentIteration) {
Author currentAuthorBeingIteratedOver
= authorsFromNameQuery[indexOfAuthorInCurrentIteration]
// do something with the author
}

---------------

Nobody is saying you have to use super long names here, what you are
saying is that less characters more % reduction in complexity, which
leads to this

for (int i=0; i <= aq.length; ++i) {
Author aa = aq[i];

// do something with the author
}

Which I don't think results in any % less chances of bugs, as a matter
of fact it ends up being less readable than some reasonable and clear
names that could have been applied.

I hope in your code reviews you are not doing character counts and
blasting developers on these bogus measurements.

[Liam Knox]

Should we go back to measuring productivity by lines of code written?

[Kevin Wright]

No, because that's based on an assumption that more lines = more functionality

Though I can see how those in favour of not removing boilerplate, and questioning the benefits of a 30% reduction might see this as a good metric

[Reinier Zwitserloot]

Isn't this fantastic? The "Author aa" part is just adding pointless
confusion, but using 'i' as a loop counter is standard practice and by
sticking to just 'i', those reading the code get a quick visual cue.
In other words, shortening indexOfAuthorInCurrentIteration to 'i' is a
significant improvement in readability. Not really because 'i' is
short, though.

Also, while descriptive variable names are important,
"currentAuthorBeingIteratedOver" is silly. just "author" will be fine;
by declaring it inside the loop, its context is limited to a single
iteration within it, and thus the 'currentXBeingIteratedOver' part is
implicit.

Not stating the obvious aids readability. That's probably the biggest
source of code readability you can find and covers both DRY violations
and boilerplate, as well as overly wordy variable names.

On the other hand, shortening 'author' to 'a' IS a pointless reduction
and actively hurts readability, even if it is shorter.

Neither wordiness nor conciseness are by themselves acceptable
standards of code quality and readability. It's just not that easy!

Interesting aside: When Microsoft and IBM decided to work together on
OS/2, IBM firmly believed that length of code indicated quality, and
thus measured everything in LOCs written. Naturally, IBM engineers
added boatloads of boilerplate: Comments stating the obvious, saving
the results of intermediate expressions to variables taken to an
extreme, and other such practices that are very effective at inflating
LOC while only hurting readability. They got better paid when they did
it, what would you expect would happen?

At the same time, microsoft was back then very much in the conciseness
trumps all phase. You wouldn't expect it (during this time VB was
released, which isn't exactly a concise language), but I hear from
various people that worked there at the time that this was essentially
true. Certainly measuring code progress by LOCs written was abhorrent
to Gates and crew, and some have pointed the finger directly at this
fundamental difference between the two teams for the flop that was the
M$+IBM joint venture OS/2. M$ decided to cancel their original plan to
phase out windows in favour of OS/2, bought a bunch of VMS talent, and
started work on NT instead. IBM took over all OS/2 development, and
the rest is history.

On Oct 25, 3:26 pm, Augusto Sellhorn <augusto.sellh...@gmail.com>
wrote:

[Kevin Wright]

Reinier: Quite right!

Now... to recall my stated example:

for(int indexOfAuthorInCurrentIteration=0; indexOfAuthorInCurrentIteration<=authorsFromNameQuery.length; ++indexOfAuthorInCurrentIteration) {

  Author currentAuthorBeingIteratedOver = authorsFromNameQuery[indexOfAuthorInCurrentIteration]

  // do something with the author

}

So nobody spotted it then?  How about I try with a shorter form, perhaps a little more obvious once the structure is exposed:

for(int i = 0; i <= authors.length; ++i) {

  Author author = authors[i]

  // do something with the author

}

Round about now, you should all be kicking yourselves for not noticing the intentional mistake in the first place...  I think this has quite effectively demonstrated my claim that boilerplate obscures errors; and in a real example with actual code, no less! (i.e. not just rhetoric)

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Ricky Clarkson]

Ooh, you clever bugger. I'm glad I wasn't on the opposite side!

[Miroslav Pokorny]

@Kevin
You also said that some languages require 30x (!) less typing than assembly which is a nonsense statement, as will demonstrated by the sample below.

Look the ARM assembly version is has less/almomst the same tokens (i cant be bothered to check but i know the ratio is not 1:5 or 1:30) than the c version.

http://en.wikipedia.org/wiki/ARM_architecture

In the C programming language, the loop is:

    while(i!=j) {
       if (i > j)

           i -= j;
       else
           j -= i;
    }

In ARM assembly, the loop is:

 loop   CMP    Ri, Rj       ; set condition "NE" if (i != j),
                            ;               "GT" if (i > j),

                            ;            or "LT" if (i < j)
        SUBGT  Ri, Ri, Rj   ; if "GT" (greater than), i = i-j;

        SUBLT  Rj, Rj, Ri   ; if "LT" (less than), j = j-i;
        BNE    loop         ; if "NE" (not equal), then loop

[Liam Knox]

Yes fantastic metric characters are in measuring bolierplate

i.e

foo() {

t.s();

t.c();

}

or

@Transactional

foo(){}

[Mark Volkmann]

I'm guessing you prefer the second case with the annotation. I believe
Kevin would too since it has fewer tokens. I agree that using the
annotation makes the meaning more clear.

--
R. Mark Volkmann
Object Computing, Inc.

[Ricky Clarkson]

Can you tell me what that computes? I can follow the C version but I
can't tell the purpose.

On Mon, Oct 25, 2010 at 10:39 PM, Miroslav Pokorny

[Liam Knox]

But equally I could say @Tx, Does this make the code any more or less understandable than @Transactional ?

Perhaps I could have a transactional keyword...

How can something like 'number of characters' or '30%' make real sense when its comes to something as subjective.

[Mark Volkmann]

I thought it was already established that we are talking about numbers
of tokens, not numbers of characters, with the added advice that some
names are unnecessarily long. I think we would all agree that
"Transactional" is not unnecessarily long.

[Kevin Wright]

No, I didn't.  You've misread and combined the following previous quotes:

"1. low-level language, requiring 30 lines of code"

and

"Assembly - Many lines"

And I never mentioned "C", not anywhere!

I'd never state that "assembly is 30x longer", because the statement is absolute nonsense without specifying *which* assembly language I meant - and there are many...

Please stop criticising things that I haven't actually said and using them as a diversionary tactic, it's getting to be quite frustrating.

[Kevin Wright]

On 26 October 2010 00:00, Liam Knox <liam...@gmail.com> wrote:

But equally I could say @Tx, Does this make the code any more or less understandable than @Transactional ?

Perhaps I could have a transactional keyword...

How can something like 'number of characters' or '30%' make real sense when its comes to something as subjective.

@Tx is valid, I see no reason why it should be misunderstood in the right context.

[Augusto Sellhorn]

Annotations are a funny thing, you can (like anything) also abuse
them. There's a project out there (don't know if I should point it
out) that decided to create listeners via annotations instead of
listener interfaces.

It actually ends up with the code being less clear than the
alternative.

ex:

public class TrumpetTest implements TrumpetListener{
public void playTrumpet(Event ev) {
}

public Test() {
Trumpet trumpet = new Trumpet ();
trumpet .addTrumpetListener(this);
}
}

vs

@Listener
public class TrumpetTest {
@PlayTrumpet
public void annotatedListen(Event ev) {
}

public Test() {
Trumpet trumpet = new Trumpet ();
trumpet .addListener(this);
}
}

Now the annotation approach makes it so that there are less
addXXXListener() methods, and I can have an uber listener that has a
list of annotations (@PlayTrumpet, @FixTrumpet, etc) but this makes
the code harder to maintain.

The annotation makes it so there's only one method signature for the
events, with a shared event object and also (at least in the API I'm
talking about) you can tag a method with an annotation with different
args, you just don't get the event (or even know about the contract
for the event).

Horrible!

On Oct 25, 6:41 pm, Liam Knox <liamjk...@gmail.com> wrote:
> Yes fantastic metric characters are in measuring bolierplate
>
> i.e
>
> foo() {
> t.s();
>
> t.c();
>
> }
>
> or
>
> @Transactional
> foo(){}
>

> On Mon, Oct 25, 2010 at 10:31 PM, Kevin Wright <kev.lee.wri...@gmail.com>wrote:
>
>
>
>
>
>
>
> > No, because that's based on an assumption that more lines = more
> > functionality
>
> > Though I can see how those in favour of not removing boilerplate, and
> > questioning the benefits of a 30% reduction might see this as a good metric
>

> >>> javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> >>> .

> >>> For more options, visit this group at
> >>>http://groups.google.com/group/javaposse?hl=en.
>
> >>  --
> >> You received this message because you are subscribed to the Google Groups
> >> "The Java Posse" group.
> >> To post to this group, send email to java...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/javaposse?hl=en.
>
> > --
> > Kevin Wright
>

> > mail / gtalk / msn : kev.lee.wri...@gmail.com

> > pulse / skype: kev.lee.wright
> > twitter: @thecoda
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to java...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> > .

[Cédric Beust ♔]

> Horrible!

I disagree.

I started thinking in that direction not long ago and I went in more details about these ideas in this post called "Local message bus".

I think this approach has merit and like you say, it saves tons of code by avoiding the proliferation of PropertyChangeSupport objects everywhere and also by not forcing listeners to implement interfaces while they only care about one or two methods. It also decouples objects from observers radically to the point of having n+m connections instead of n*m (at the cost of having all these objects depend on the same local bus).

Overall, I haven't found this compelling enough to start exposing it in TestNG but I'm not far from making the jump.

-- 

Cédric

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Cédric

[Augusto Sellhorn]

Maybe the implementation of this idea that I'm looking at is bad.

The problem is the annotation doesn't give you an idea of what the
method should support to receive the event object. It is done in a way
that works with no parameters in the method, or any parameters in the
method.

That is

@PlayTrumpet
public void annotatedListen(Event ev) {
}

Works (and you get the "event")

@PlayTrumpet
public void annotatedListen() {
}

Works, and obviously you get no event

@PlayTrumpet
public void annotatedListen(String trumpet) {
}
Works, and you don't get the event

@PlayTrumpet
public void annotatedListen(String trumpet, Event event) {
}

I have no idea what it does!!!!

This is almost annotation abuse because you don't clearly know what
the contract is to get the event, which I think is bad API design.

(Oh and not annotating the class as a @Listener ... results in your
listener not working, that's another pain point)

On Oct 26, 10:51 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
> > Horrible!
>
> I disagree.
>
> I started thinking in that direction not long ago and I went in more details
> about these ideas in this post called "Local message

> bus"<http://beust.com/weblog/2010/07/26/local-message-bus/>

> Cédric

[Mark Volkmann]

That reminds me of JUnit 4. Supposedly the @Test annotation is a good
thing. I don't see how the ability to create test methods whose names
do not begin with "test" is a good thing.

> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
>
>

--

[Marcelo Fukushima]

i guess one could count the ability to create test cases without extending TestCase could count as a positive thing

http://mapsdev.blogspot.com/
Marcelo Takeshi Fukushima

[Cédric Beust ♔]

On Wed, Oct 27, 2010 at 3:55 AM, Mark Volkmann <r.mark....@gmail.com> wrote:

That reminds me of JUnit 4. Supposedly the @Test annotation is a good
thing. I don't see how the ability to create test methods whose names
do not begin with "test" is a good thing.

It gives you more flexibility to name your methods and it also lets you specify @Test at the class level to include all public methods as test methods (that's a TestNG feature though, I don't think JUnit supports it). It also enables inheritance (extend a base class with a @Test method and all your public methods automatically become test methods).

The "test" introspection thing has always been a hack because we had nothing better. Now we do.

--
Cédric

[Cédric Beust ♔]

On Wed, Oct 27, 2010 at 7:35 AM, Marcelo Fukushima <take...@gmail.com> wrote:

i guess one could count the ability to create test cases without extending TestCase could count as a positive thing

It is definitely a good thing but it's not related to forcing you to have your method names start with "test".

--
Cédric

[Mark Volkmann]

2010/10/27 Cédric Beust ♔ <ced...@beust.com>:

I wonder though if most people still give their test methods names
that begin with "test". I do. One reason is so the test methods stand
out in my IDE within the list of methods in the class. I want some way
to visually distinguish between test methods and utility methods
within the test class.

[Cédric Beust ♔]

On Wed, Oct 27, 2010 at 11:55 AM, Mark Volkmann <r.mark....@gmail.com> wrote:

I wonder though if most people still give their test methods names
that begin with "test". I do. One reason is so the test methods stand
out in my IDE within the list of methods in the class. I want some way
to visually distinguish between test methods and utility methods
within the test class.

Yes but this can be easily solved with a tool. Writing an updated Eclipse Outline view to group methods by annotations is a matter of a few hours. Hey I might even go ahead and write it myself.

The thing is: most of the methods in my tests classes are test methods, so the need for this is not that high, at least to me.

As for naming, yes, old habits die hard and it's easy to just start your method name with "test", but I find myself being more and more creative with this now ("shouldThrowException", "userShouldBePresent", etc...). And I always have the handy `description` attribute if I am in a verbose mood (@Test(description = "Make sure we have exactly one user named Smith in the db"), something that you can't do without annotations.

-- 

Cédric

[Joakim Olsson]

On Wed, Oct 27, 2010 at 8:55 PM, Mark Volkmann <r.mark....@gmail.com> wrote:

I wonder though if most people still give their test methods names
that begin with "test". I do. One reason is so the test methods stand
out in my IDE within the list of methods in the class. I want some way
to visually distinguish between test methods and utility methods
within the test class.

I rarely give my tests names that start with test after reading the book Growing Object Oriented Software: Guided by tests.

My test-methods usually have quite long names describing what I'm actually testing in that very method.

Regards,

Joakim

[Kevin Wright]

2010/10/27 Cédric Beust ♔ <ced...@beust.com>

I'm sorry, but, yes that can be done without annotations:

http://www.scalatest.org/getting_started_with_fun_suite

http://code.google.com/p/specs/

and before anyone starts screaming "Oh no, not Scala again!", there's no reason why you can't restrict it to just testing - It's quite possibly the best use case I've seen so far for an internal DSL, and it doesn't touch production code in any way.

You won't find yourself using annotations to subvert the type-system or extend the language in any way and, frankly, if you're in the position that you need to add extra support to the IDE anyway, then you may as well do it for something that's just a *little* bit more flexible than adding a few test cases!

Having said all that, I totally agree that having the word "test" in method or class names is a pretty Bad Thing(tm).  If you're working with BDD then you'll be writing specifications, not tests.

 

-- 

Cédric

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Kevin Wright

mail / gtalk / msn : kev.lee...@gmail.com

[Cédric Beust ♔]

Please, just go away.

-- 

Cédric

On Wed, Oct 27, 2010 at 12:55 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

2010/10/27 Cédric Beust ♔ <ced...@beust.com>

On Wed, Oct 27, 2010 at 11:55 AM, Mark Volkmann <r.mark....@gmail.com> wrote:

I wonder though if most people still give their test methods names
that begin with "test". I do. One reason is so the test methods stand
out in my IDE within the list of methods in the class. I want some way
to visually distinguish between test methods and utility methods
within the test class.

Yes but this can be easily solved with a tool. Writing an updated Eclipse Outline view to group methods by annotations is a matter of a few hours. Hey I might even go ahead and write it myself.

The thing is: most of the methods in my tests classes are test methods, so the need for this is not that high, at least to me.

As for naming, yes, old habits die hard and it's easy to just start your method name with "test", but I find myself being more and more creative with this now ("shouldThrowException", "userShouldBePresent", etc...). And I always have the handy `description` attribute if I am in a verbose mood (@Test(description = "Make sure we have exactly one user named Smith in the db"), something that you can't do without annotations.

I'm sorry, but, yes that can be done without annotations:

http://www.scalatest.org/getting_started_with_fun_suite

http://code.google.com/p/specs/

and before anyone starts screaming "Oh no, not Scala again!"

--
Cédric

[Ricky Clarkson]

In our larger Java projects, we do use Scala for some of the unit
tests, particularly with Specs. Specs is very good, though I'm sure a
DSL for Java that does similar things could be concocted easily, and
probably already exists.

[Liam Knox]

I think annotations and interfaces have to be looked at as different, which obviously they are, but with some overlap in functional context. If you really want some object to have a concrete and binding function which must be obeyed by all then interfaces give you that.  Annotations however give you more flexibility to decorate and define use case.  

Classic is JUnit where you want to define what methods are Testable and can also extend to define what exceptions are expected.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Kevin Wright]

Does nobody else worry that a great deal of what's nowadays called "Java" isn't actually Java.

It's a mix of XML configuration files and annotations.  Needing specialist IDE support, existing outside the type system, interpreted at runtime...  A true proto-language in fact!

That's your DSL for Java;  Something written in any way possible, just so long as it stays as far away from the core language as possible (e.g. annotations), and possibly outside it entirely (xml, anyone?).  Just consider Spring, Hibernate, etc.

So by all means, defend this as the status quo, but don't pretend to be defending "pure Java" against alternative languages as you do so - because you're already using alternative languages.  Worse still, you're promoting the rise of "interpreted XML & annotations" as being more Java-like than something which compiles down to bytecode, which is just plain wrong.

2010/10/27 Cédric Beust ♔ <ced...@beust.com>

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Miroslav Pokorny]

Who says everyone uses xml everywhere ?