Re: [The Java Posse] Re: ScalaDBTest 0.1

Who says everyone uses xml everywhere ? -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For

Re: [The Java Posse] Re: ScalaDBTest 0.1

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 Ja

Re: [The Java Posse] Re: ScalaDBTest 0.1

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 yo

Re: [The Java Posse] Re: ScalaDBTest 0.1

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. On Wed, Oct 27, 2010 at 8:55 PM, Kevin Wright wrote: > > 2010/10/2

Re: [The Java Posse] Re: ScalaDBTest 0.1

Please, just go away. -- Cédric On Wed, Oct 27, 2010 at 12:55 PM, Kevin Wright wrote: > 2010/10/27 Cédric Beust ♔ > >> >> >> On Wed, Oct 27, 2010 at 11:55 AM, Mark Volkmann < >> r.mark.volkm...@gmail.com> wrote: >> >>> >>> >>> I wonder though if most people still give their test methods names

Re: [The Java Posse] Re: ScalaDBTest 0.1

2010/10/27 Cédric Beust ♔ > > > On Wed, Oct 27, 2010 at 11:55 AM, Mark Volkmann > 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

Re: [The Java Posse] Re: ScalaDBTest 0.1

On Wed, Oct 27, 2010 at 8:55 PM, Mark Volkmann 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 be

Re: [The Java Posse] Re: ScalaDBTest 0.1

On Wed, Oct 27, 2010 at 11:55 AM, Mark Volkmann 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

Re: [The Java Posse] Re: ScalaDBTest 0.1

2010/10/27 Cédric Beust ♔ : > > On Wed, Oct 27, 2010 at 3:55 AM, Mark Volkmann > 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

Re: [The Java Posse] Re: ScalaDBTest 0.1

i guess one could count the ability to create test cases without extending TestCase could count as a positive thing On Wed, Oct 27, 2010 at 8:55 AM, Mark Volkmann 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 met

Re: [The Java Posse] Re: ScalaDBTest 0.1

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. On Tue, Oct 26, 2010 at 6:36 PM, Augusto Sellhorn wrote: > Annotations are a funny thing, you can (like anything) a

[The Java Posse] Re: ScalaDBTest 0.1

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

Re: [The Java Posse] Re: ScalaDBTest 0.1

> 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 avoid

[The Java Posse] Re: ScalaDBTest 0.1

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:

Re: [The Java Posse] Re: ScalaDBTest 0.1

On 26 October 2010 00:00, Liam Knox 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

Re: [The Java Posse] Re: ScalaDBTest 0.1

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. On Mon, Oct 25, 2010 at 6:00 PM, Liam Knox wrote: >

Re: [The Java Posse] Re: ScalaDBTest 0.1

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. On Tue, Oct 26, 2010 at 7:54

Re: [The Java Posse] Re: ScalaDBTest 0.1

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. On Mon, Oct 25, 2010 at 5:41 PM, Liam Knox wrote: > Yes fantastic metric characters are in measuring bolierplate > i.e

Re: [The Java Posse] Re: ScalaDBTest 0.1

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 wrote: > No, because that's based on an assumption that more lines = more > functionality > > Though I can see how those in favou

Re: [The Java Posse] Re: ScalaDBTest 0.1

Ooh, you clever bugger. I'm glad I wasn't on the opposite side! On Mon, Oct 25, 2010 at 8:52 PM, Kevin Wright wrote: > Reinier: Quite right! > Now... to recall my stated example: > for(int > indexOfAuthorInCurrentIteration=0; indexOfAuthorInCurrentIteration<=authorsFromNameQuery.length; > ++inde

Re: [The Java Posse] Re: ScalaDBTest 0.1

Reinier: Quite right! Now... to recall my stated example: for(int indexOfAuthorInCurrentIteration=0; indexOfAuthorInCurrentIteration<=authorsFromNameQuery.length; ++indexOfAuthorInCurrentIteration) { Author currentAuthorBeingIteratedOver = authorsFromNameQuery[indexOfAuthorInCurrentIteration]

[The Java Posse] Re: ScalaDBTest 0.1

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 improvem

Re: [The Java Posse] Re: ScalaDBTest 0.1

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 On 25 October 2010 14:28, Liam Knox wrote: > Should we go back to mea

Re: [The Java Posse] Re: ScalaDBTest 0.1

Should we go back to measuring productivity by lines of code written? On Mon, Oct 25, 2010 at 10:26 PM, Augusto Sellhorn < augusto.sellh...@gmail.com> wrote: > 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 tha

[The Java Posse] Re: ScalaDBTest 0.1

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; indexOfAuthorInCurrentIteratio

[The Java Posse] Re: ScalaDBTest 0.1

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 On Oct 23, 4:19 pm, Ken Egervari wrote: > Yes, I do (hopef

[The Java Posse] Re: ScalaDBTest 0.1

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 ;) On Oct 23, 11:19 am, Ken Egervari wrote: > Yes, I do (hopefully). > > It's not implemented yet, but it's next o

[The Java Posse] Re: ScalaDBTest 0.1

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:

[The Java Posse] Re: ScalaDBTest 0.1

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 i

[The Java Posse] Re: ScalaDBTest 0.1

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 star

[The Java Posse] Re: ScalaDBTest 0.1

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(