The Artima Developer Community
Sponsored Link

Weblogs Forum
ScalaTest 0.9 Released

58 replies on 4 pages. Most recent reply: Jan 21, 2008 6:26 AM by Bill Venners

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 58 replies on 4 pages [ « | 1 2 3 4 | » ]
Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 11:21 AM
Reply to this message Reply
Advertisement
> > Yes, and frankly, I think that the assertEquals
> > nomenclature from JUnit was a mistake. Equality isn't
> > what the assertion is about, it's about testing an
> actual
> > given an expectation and it should've been named that
> way,
> > with a name that indicated its asymmetry.
> >
> > It's easy to say that all of these stuff doesn't
> matter,
> > but it does. Good affordances eliminate a lot of
> > confusion. If you can eliminate confusion with a good
> > name, why not?
> >
> In Scala, you can say assert(a == b) anywhere. "assert" is
> a method defined in PreDef, which is imported into every
> Scala file implicitly. My take was that === means
> essentially the same thing as ==, except with a more
> helpful message contained in the AssertionError that
> results if there's a failure. assert(a == b) and assert(a
> === b) differ only in the contents of that message.
> Otherwise their behavior is the same. So === does seem
> about equality to me conceptually.
>
> I toyed with other names for ===. It is a bit long, and I
> found it easy to forget the extra = sign sometimes. But
> Haskell's @=? looks pretty ugly to me at first blush. ==?
> could work. But then you have to hit two different keys, =
> and ?, and the shift key for the ?. People who use
> ScalaTest will type this a lot.
>
> assert(a ==? b)
>
> It looks kind of funky to me.

Fair enough. I didn't realize that assert wasn't part of the framework. It's interesting because Scala, like Haskell and OCaml allow the creation of new operators and people have to figure out what will be intuitive and what will throw people.

I've been working with Haskell and OCaml a bit, and I've been trying to figure out what makes sense and what doesn't based upon all of the examples I've been seeing. I like words but often it seems that symbols work better for highly repetitive stuff. My last few blogs over here ( http://beautifulcode.oreillynet.com/ ) have been about that.

I wonder, though, whether anyone else see is this way.. that lexical symmetry in an operator seems to imply semantic symmetry? Bill, yes, === is a form of equality, but unless you go for Elizabeth's suggestion of dropping expected and actual, it really is asymmetric.

Is != the only lexically asymmetric operator that is semantically symmetric in common programming languages?

Michael (trying to think of other examples)

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 11:29 AM
Reply to this message Reply
> I was thinking of grape and salmon as colors. :-)

I really should eat breakfast in he morning. :-)

> Nevertheless, JUnit's assertEquals cannot discern that its
> right argument comes from a method under test and its left
> argument is the expected output of that method.

Yeah, and if it were named matchExpectToActual or something like that, it would be hard to screw up, although a devil without code completion.

> We're
> accustomed to using it that way because the JavaDocs say
> assertEquals(expected, actual) and because consultants and
> book authors say that's what assertEquals is for. ;-) Even
> Dive into Python uses it like that.

Except when they switch actual and expected around :-( I guess people who don't switch between languages all that often don't have to deal with it, but it's a nit for people who do.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 11:31 AM
Reply to this message Reply
<slightly curmudgeony mode>

So you guys are all excited about being able to type

assert (a === b)

But then there are dozens of posts about what is the expected answer and what is the answer the test code generated. Plus a BUG.

May I suggest that longer, more explicit code that, sheesh, you have to type a bit more is BETTER?

assertEquals(expected, actual)

is self documenting. We've already wasted more time arguing and discussing than in typing.

</slightly curmudgeony mode>


p.s. I do like the "expect an execption syntax

Bill Venners

Posts: 2249
Nickname: bv
Registered: Jan, 2002

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 11:36 AM
Reply to this message Reply
> Well... not everything has to smell like Java and a
> testing framework doesn't have to smell like JUnit. So the
> question is, what nomenclature/syntax is in the spirit of
> Scala?
>
I do want JUnit 3 folks to be comfortable in ScalaTest, as well as JUnit 4 and TestNG folks, but especially JUnit 3, because as far as I know that's the largest group of people.

You ask a good question. I think we're still figuring out what the spirit of Scala is. There's a lot of heated debate between OO folks and FP folks on the Scala mailing lists. The language blends OO and FP very nicely, but the people blend with a bit of friction. A kind of clash of cultures.

Anyway, === uses operator characters and assert(a === b) uses an implicit conversion. Both of those I think should be avoided except when absolutely justified. I felt it was justified here because we write so many assertions, and we really do want the expected and actual values to be reported if there's an AssertionError, and assert(a === b) looks pretty darn natural. It's an example of how Scala can "scale" to different application domains. This is the testing domain, and I was able to extend the language so to speak to create an API that feels like native language support. The other part of that was being able to make the expect exception control abstraction.

I asked Martin Odersky maybe six months ago if === was being used anywhere in Scala land, and he said he wasn't aware of it. I've been mentioning my use of === on the Scala mailing list for months. I did discover only this week that ScalaCheck uses === and !== to mean something different. So I'll need to take that up with Rickard Nilsson. He may have chosen those because Haskell's QuickCheck did. Not sure.

I'll ask the Scala list what they think of ===. That will give me feedback from the Scala community on whether === is in the right "spirit" or not.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 11:39 AM
Reply to this message Reply
> I wonder, though, whether anyone else see is this way..
> that lexical symmetry in an operator seems to imply
> semantic symmetry? Bill, yes, === is a form of equality,
> but unless you go for Elizabeth's suggestion of dropping
> expected and actual, it really is asymmetric.
>
> Is != the only lexically asymmetric operator that is
> semantically symmetric in common programming languages?

I really, really do think of Python's "assertEqual(first, second)" as semantically symmetric. And I figure its author does, too, because the failing test produces plain ol' "first != second". It only differs from "assert(first == second)" in that it outputs the two values for me instead of leaving me to marvel at the fact that False is not True.

IIRC, Bill said above that the difference between "assert(a === b)" and "assert(a == b)" is that "assert(a === b)" outputs the two values upon failure and "assert(a == b)" doesn't. I believe he is free to decide whether his === operator should be considered semantically symmetric.

Bill Venners

Posts: 2249
Nickname: bv
Registered: Jan, 2002

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 12:07 PM
Reply to this message Reply
> IIRC, Bill said above that the difference between
> "assert(a === b)" and "assert(a == b)" is that "assert(a
> === b)" outputs the two values upon failure and "assert(a
> == b)" doesn't. I believe he is free to decide whether his
> === operator should be considered semantically symmetric.
>
I'm not sure what you mean by "semantically symmetric", or plain old "symmetric" for that matter. What I assumed it meant is that a == b means the same thing as b == a.

I would question whether assertEquals(first, second) is any more or less symmetric than assertEquals(expected, actual), because in both cases the behavior is the same except that the String message in the AssertionError is different.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 12:12 PM
Reply to this message Reply
> I would question whether assertEquals(first, second) is
> any more or less symmetric than assertEquals(expected,
> actual), because in both cases the behavior is the same
> except that the String message in the AssertionError is
> different.

Right, but to me at least, that message is an integral part of the semantics and the thing that makes the expected/actual version asymmetric. I agree that first/second is symmetric.

If switching the args around makes the message wrong, it's asymmetric because we don't get the right behavior.

Bill Venners

Posts: 2249
Nickname: bv
Registered: Jan, 2002

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 12:13 PM
Reply to this message Reply
> <slightly curmudgeony mode>
>
> So you guys are all excited about being able to type
>
> assert (a === b)
>
> But then there are dozens of posts about what is the
> expected answer and what is the answer the test code
> generated. Plus a BUG.
>
> May I suggest that longer, more explicit code that,
> sheesh, you have to type a bit more is BETTER?
>
> assertEquals(expected, actual)
>
> is self documenting. We've already wasted more time
> arguing and discussing than in typing.
>
> </slightly curmudgeony mode>
>
In the documentation I say assert(actual === expected), and the original comment was that those are reverse JUnit order. I'm leaning towards switching the order in the next release, but it would then be assert(expected === actual), which I think carries the same meaning as assertEquals(expected, actual). Only the parameter names are "expected" and "actual". People in either case could pass an actual value in the expected parameter, and vice versa.

>
> p.s. I do like the "expect an execption syntax
>
OK. Thanks. That's one +1 vote. So far 1 to 0 in favor.

Bill Venners

Posts: 2249
Nickname: bv
Registered: Jan, 2002

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 12:14 PM
Reply to this message Reply
> > I would question whether assertEquals(first, second) is
> > any more or less symmetric than assertEquals(expected,
> > actual), because in both cases the behavior is the same
> > except that the String message in the AssertionError is
> > different.
>
> Right, but to me at least, that message is an integral
> part of the semantics and the thing that makes the
> expected/actual version asymmetric. I agree that
> first/second is symmetric.
>
> If switching the args around makes the message wrong, it's
> asymmetric because we don't get the right behavior.
>
Ah. That's true. In once case passing in actual for expected makes the message false, and in the other case not.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 12:53 PM
Reply to this message Reply
Hi Bill,

Nice job with ScalaTest! I'll have to take a closer look, it will be interesting to see how testing paradigms adapt to Scala.

I like the fact that the test discovery mechanism can be overridden simply, but it also scares me somewhat. I think it might be an example where less flexibility is more desirable, or you will end up with someone sending you a ScalaTest class example and you will have no idea which ones are test methods because they overrode that behavior...

Obviously, I'm partial to the annotation approach because it lets you specify attributes... For example, how would you specify a test method with a time out?

Similarly, I need to think more about the fact that each class can override its own execute method. In the JUnit world, a lot of people seem to want custom runners to do all kinds of things, but very few people have made similar requests for TestNG because a lot of the features users ask for are already built in. In echo to my previous point, I would encourage you to think about a world where hundreds of ScalaTest classes can each have a different way to identify test methods *and* a different way to actually run...

Another quick thought: I strongly recommend giving priority to an Eclipse plug-in over a Maven one. TestNG's popularity spiked really hard as soon as an Eclipse plug-in was made available. The Maven crowd will come to you once your tool becomes more popular, and trust me, you really don't want to get into Maven with an alpha version of your code...

Back to your question...

To be honest, I thought I had a good reason to put the value first and expected second but I can't remember it now... Off the top of my head, I would say it's because putting expected first reminds me of

if (null == foo)

which is obsolete in Java and more often written

if (foo == null)

Putting expected first also makes sense since it mimics the failure message, which is typically "Expected 'exp' but got 'val'".

So all in all, I don't feel strongly either way.

What I do remember is that I purposely moved the string diagnosis to the end of the parameter list.

I have never liked to see this string as first parameter in JUnit's assert methods because when I read the assert, this is the last thing I'm interested in. What I want to know first and foremost is the expected value (another minor argument in favor of putting the expected value first). Of course, one might argue that you'd want to see the value under test first in the assert...

--
Cedric

Bill Venners

Posts: 2249
Nickname: bv
Registered: Jan, 2002

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 1:44 PM
Reply to this message Reply
> Hi Bill,
>
> Nice job with ScalaTest! I'll have to take a closer look,
> it will be interesting to see how testing paradigms adapt
> to Scala.
>
> I like the fact that the test discovery mechanism can be
> overridden simply, but it also scares me somewhat. I
> think it might be an example where less flexibility is
> more desirable, or you will end up with someone sending
> you a ScalaTest class example and you will have no idea
> which ones are test methods because they overrode that
> behavior...
>
> Obviously, I'm partial to the annotation approach because
> it lets you specify attributes... For example, how would
> you specify a test method with a time out?
>
I didn't support timeouts yet. The way you'd probably do that in Scala is with a control abstraction, like


withTimeout(1000) {
// do something
}


Then let that throw an assertion error that indicates the problem was a timeout in the report. A few things that you used annotations for in TestNG I think are smoother with control abstractions, because the annotations approach requires that you make a test method for each. Whereas with a control abstraction, you can put multiple timeout tests or multiple expected exception tests in the same test method:


def testSomething() {

expectNPE {
throw new NullPointerException
}

expectNPE {
"hi".contains(null)
}

withTimeout(1000) {
// do one thing
}

withTimeout(2000) {
// do something else
}
}


But another way they could do it is extend TestNGSuite or JUnit4Suite and use TestNG's or JUunit4's timeout annotation on a test method.


class MySuite extends TestNGSuite {

@Test(threadPoolSize = 3, invocationCount = 10, timeOut = 10000)
def testServer() {

// do something, but in here you can use ScalaTest-like assertion syntax
assert(a === b)
expect(classOf[ServerException]) {
// do something else
}
}
}


Basically I would like ScalaTest to make it easy to write TestNG or JUnit tests that then use the nice assertion and expected exception syntax made possible by Scala, as well as property-based tests a la ScalaCheck. That way people using JUnit or TestNG can continue to do so, but write the code in Scala in a style that's more natural to Scala.

Anyway, I didn't support timeouts because I have never needed them and didn't know what people really wanted. I figured I'd wait until people ask. For the time being, it is quite straigtforward for people who need it to make a withTimeout-like control abstraction of their own.

> Similarly, I need to think more about the fact that each
> class can override its own execute method. In the JUnit
> world, a lot of people seem to want custom runners to do
> all kinds of things, but very few people have made similar
> requests for TestNG because a lot of the features users
> ask for are already built in. In echo to my previous
> point, I would encourage you to think about a world where
> hundreds of ScalaTest classes can each have a different
> way to identify test methods *and* a different way to
> actually run...
>
Well I think that was the world I was envisioning. It is more an OO approach of asking an object to use its data in an interesting way rather than doing something to the object from the outside.

Also, "test" is more abstract than "test method". A test method is one kind of test you can report. But a test is just anything that has a name, can be started, will either succeed or fail, and can optionally be ignored. That's about it. So another way people may want to express tests in ScalaTest is as function values. You can see an example of that approach here:

http://rehersal.sourceforge.net/documentation.shtml#writingTests

Except I'd do it this way:


test("Example of a test that will fail") {
fail()
}


In this approach, test is a method that registers the function value, which then would get invoked when execute is invoked on the Suite. This would look foreign to JUnit users I think, but may feel more natural to functional programming folks. I want to have a Suite to facilitate this kind of testing too. I don't think anyone used Rehersal much, so I probably won't make a RehersalSuite. I'll probably call this FunctionalSuite or something.

Another way is wrapping existing JUnit/TestNG, etc., tests written in Java. Tests in such suites would be JUnit/TestNG test methods. Although those are also "test methods."

But it could be anything else too, really, so people have a lot of leeway to integrate existing Java test code into ScalaTest suites, so they can support the old tests in Java and write new ones in Scala.

> Another quick thought: I strongly recommend giving
> priority to an Eclipse plug-in over a Maven one. TestNG's
> popularity spiked really hard as soon as an Eclipse
> plug-in was made available. The Maven crowd will come to
> you once your tool becomes more popular, and trust me, you
> really don't want to get into Maven with an alpha version
> of your code...
>
OK. I have never used Maven. It just seemed like the next step after Ant. I'll definitely look into the plug ins, and also contact the folks making the Scala plug ins.

> Back to your question...
>
> To be honest, I thought I had a good reason to put the
> value first and expected second but I can't remember it
> now... Off the top of my head, I would say it's because
> putting expected first reminds me of
>
> if (null == foo)
>
> which is obsolete in Java and more often written
>
> if (foo == null)
>
Interesting. In Scala you can do either:


scala> null == "hi"
res0: Boolean = false

scala> "hi" == null
res1: Boolean = false


> Putting expected first also makes sense since it mimics
> the failure message, which is typically "Expected 'exp'
> but got 'val'".
>
> So all in all, I don't feel strongly either way.
>
OK. I'm definitely leaning towards changing it to assert(expected === actual) then.

> What I do remember is that I purposely moved the string
> diagnosis to the end of the parameter list.
>
Me too. I did this in SuiteRunner in 2001.

> I have never liked to see this string as first parameter
> in JUnit's assert methods because when I read the assert,
> this is the last thing I'm interested in. What I want to
> know first and foremost is the expected value (another
> minor argument in favor of putting the expected value
> first). Of course, one might argue that you'd want to see
> the value under test first in the assert...
>
Elvin Eklund mentioned in this forum that they thought it was more readable with expected first, because the expected expression was usually shorter (fewer characters). I looked in my tests and found that to be true. I think he may be right that having the usually shorter one first improves readability.

Bill Venners

Posts: 2249
Nickname: bv
Registered: Jan, 2002

Re: ScalaTest 0.9 Released Posted: Jan 16, 2008 2:41 PM
Reply to this message Reply
> Similarly, I need to think more about the fact that each
> class can override its own execute method. In the JUnit
> world, a lot of people seem to want custom runners to do
> all kinds of things, but very few people have made similar
> requests for TestNG because a lot of the features users
> ask for are already built in. In echo to my previous
> point, I would encourage you to think about a world where
> hundreds of ScalaTest classes can each have a different
> way to identify test methods *and* a different way to
> actually run...
>
One other point to note is that Suite is a trait in Scala. In SuiteRunner, Suite was a class, like TestCase in JUnit 3. So that "burns the base class." In TestNG and JUnit4, you don't burn the base class, and that's nice. In ScalaTest, I don't have to burn the base class, but can still do the OO approach of providing methods that can be overridden, because you can define concrete methods in traits, yet still extend multiple traits like you can implement multiple interfaces in Java. So with ScalaTest, like in TestNG or JUnit 4, any class can be made into a holder of tests. Instead of using annotations, though, you would mix in a Suite trait of your choosing.

Bill Venners

Posts: 2249
Nickname: bv
Registered: Jan, 2002

Re: ScalaTest 0.9 Released Posted: Jan 17, 2008 1:36 AM
Reply to this message Reply
> If switching the args around makes the message wrong, it's
> asymmetric because we don't get the right behavior.
>
I just switched the order tonight, so expected was on the left of ===, actual on the right. All looked well, but then I realized I needed to change the orders in the first example in Suite. It was originally:


import org.scalatest.Suite

class MySuite extends Suite {

def testAddition() {
val sum = 1 + 1
assert(sum === 2)
assert(sum + 2 === 4)
}

def testSubtraction() {
val diff = 4 - 1
assert(diff === 3)
assert(diff - 2 === 1)
}
}


And then I changed it to:


import org.scalatest.Suite

class MySuite extends Suite {

def testAddition() {
val sum = 1 + 1
assert(2 === sum)
assert(4 === sum + 2)
}

def testSubtraction() {
val diff = 4 - 1
assert(3 === diff)
assert(1 === diff - 2)
}
}


So now expected was first. I looked at this and it looked funny to me. I think it is because I would usually say:

1 + 1 = 2

More often than saying:

2 = 1 + 1

I also tried the left and right approach, where you don't nail down which one is actual and which expected. It makes === symmetrical, but also makes the error message a tad weak I felt. Instead of saying, "Expected 3 but got 5" it said "3 did not equal 5". That's not too bad I suppose. If someone always puts expected on the left, they'll know 3 was the expected value.

One somewhat weird possibility that I realized tonight was that you whatever solution I ultimately end up with here, someone who didn't like it could change it to their liking by subclassing Equalizer, then overriding convertToEqualizer in a custom Suite trait. They could then quite easily change the message that shows up in the AssertionError. It is a point of extension that I hadn't imagined that anyone would want to use before, but it is there. If some people are unhappy with the default, there could be Suite traits floating around that do this for the common preferred approaches (which I think are left === right, actual === expected, or expected === actual), and people could just mix in the trait with the behavior they prefer into the Suite trait they extend from all of their Suite classes.

I think the flexibility of traits is really starting to show up in these discussions about ScalaTest. There can eventually be all kinds of Suite traits that people can mix and match into a trait they use as the base of all their Suite classes, like picking a la carte from a menu of behaviors.

Anyway, nothing jumped out at me as the obvious right way to go on the === question, so I'm going to sleep on it one night at least. If anyone else has opinions or advice, please post them here.

Jörn Zaefferer

Posts: 22
Nickname: jzaefferer
Registered: Jul, 2007

Re: ScalaTest 0.9 Released Posted: Jan 17, 2008 4:08 AM
Reply to this message Reply
Bill,

the best frameworks are those that do the right thing out of the box, without me having to worry about customizing stuff just to get things done.

In other words, if people aren't happy with the defaults, the should discuss alternatives with you and other scala testers so that we get better defaults at the end of the day.

Anyway, what I was thinking about: Shouldn't it be possible to wrap ScalaTests in a JUnit TestCase/TestSuite to get them running in the JUnit Eclipse Plugin? I wouldn't mind writing the test suite in JUnit as long as all the actual tests can be written in Scala. I hope someone can explore that further.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: ScalaTest 0.9 Released Posted: Jan 17, 2008 9:31 AM
Reply to this message Reply
I had a thought, Bill, about naive versus more advanced programmers. I don't know Scala (yet), but I got to pondering C++ and writing a little Ruby experiment.

Gazing at the Suite.Equalizer doc, I notice lhs === rhs invokes lhs == rhs. So let's think of lhs == rhs for a moment. I wrote a quick and dirty Ruby assert_equal to play around with:


def assert_equal(a, b, alert=nil)
unless a == b
msg = "#{a.class} <#{a}> not equal to #{b.class} <#{b}>"
puts alert ? msg + " (#{alert.upcase})" : msg
end
end

YES = 'but should be'; NO = false
assert_equal 5, 5, YES
assert_equal 5, 7, NO


The above code, predictably, produces one error message:


Fixnum <5> not equal to Fixnum <7>


Now, an "expected" value in a test is likely to be a built-in type, but an "actual" value is more likely to be a user-defined type. And so expected == actual might invoke a different function/method than actual == expected.

In Ruby, lhs == rhs is syntactic sugar for lhs.==(rhs). In other words, lhs's '==' method gets called and the method is passed rhs as the argument.

Let's say I want a string type which always does case-insensitive comparisons. It's pretty easy to define a decent '==' method for my own user-defined type.


class CIString < String
def ==(other)
String.new(self.downcase) == other.to_s.downcase
end
end

def _string_tests
assert_equal CIString.new('betty'), CIString.new('BETTY'), YES
assert_equal CIString.new('betty'), CIString.new('wilma'), NO
assert_equal CIString.new('fred'), 'FRED', YES
assert_equal CIString.new('FRED'), 'fred', YES
assert_equal 'barney', CIString.new('BARNEY'), YES
assert_equal 'BARNEY', CIString.new('barney'), YES
assert_equal 'pebbles', 'pebbles', YES
assert_equal 'pebbles', 'PEBBLES', NO
assert_equal 'PEBBLES', 'pebbles', NO
puts
end

_string_tests()


But because I'm naive, some of the tests don't behave as desired:


CIString <betty> not equal to CIString <wilma>
String <barney> not equal to CIString <BARNEY> (BUT SHOULD BE)
String <BARNEY> not equal to CIString <barney> (BUT SHOULD BE)
String <pebbles> not equal to String <PEBBLES>
String <PEBBLES> not equal to String <pebbles>


The Barney tests, which call for case-insensitive comparison starting from a String (not a CIString), fail. I need to to muck around to get the Barney tests to pass.


class String
alias_method :old_equal_to, :==
def ==(other)
return self.old_equal_to(other) if other.class == String
other == self
end
end

_string_tests()


And now they do:


CIString <betty> not equal to CIString <wilma>
String <pebbles> not equal to String <PEBBLES>
String <PEBBLES> not equal to String <pebbles>


As I said, I don't know Scala (yet). But will a naive Scala programmer have a more difficult time getting built_in_type === user_defined_type to pass than user_defined_type === built_in_type? If so, it might be best for the docs and assertion failure messages to encourage us to put the "expected" value before the "actual" value.

Did I make any sense?

Flat View: This topic has 58 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: ScalaTest 0.9 Released Previous Topic   Next Topic Topic: What Are Your Java Pain Points, Really?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us