You message came though with from name of "None", but I'm guessing
from the rest of your email address you're actually Some(Fabio).
Please correct me if I'm wrong.
Can you elaborate on what you mean by managed object? If I understand
correctly, the input you're creating implements some interface that
has start() and a close() method, which are like lifecycle methods. So
you'd want to maybe start() it before each test and close() it after?
Is that what you mean by managed object?
Then you have multiple implementations of that interface that you need
to run the same tests across? If that's correct then I think either
shared tests or using a one-column table should work. Another
possibility, which I didn't consider before, is to call the test
function multiple times from within withFixture. I think that would
also work, and it could possibly be the place to use the table.
Please let me know if I understand your requirements correctly first,
and then I'll try and propose a solution for you. Also, which version
of ScalaTest are you using?
Thanks.
Bill
> --
> You received this message because you are subscribed to the Google
> Groups "scalatest-users" group.
> To post to this group, send email to scalate...@googlegroups.com
> To unsubscribe from this group, send email to
> scalatest-use...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/scalatest-users?hl=en
> ScalaTest itself, and documentation, is available here:
> http://www.artima.com/scalatest
>
--
Bill Venners
Artima, Inc.
http://www.artima.com
Thanks for your prompt response, and yes, I'm Some("Fabio"). =P
Well, when I say managed objects I mean objects like Input/Output
Streams, java.sql.Connection, etc, which have 'close' method that
should be called after using them.
In my case I'm working with Selenium WebDrivers [1], which contain a
method 'quit' that, from what i know, are expected to be called after
each test. So, in this way, I have a new WebDriver for each test.
WebDriver is the interface, and selenium provides one implementation
of WebDriver for each browser it supports (IE, Firefox, Chrome..).
So, my goal here is: write a test suite for a given web page and run
it using a set of WebDriver implementations.
Currently i'm using scala-test 1.6.1 and scala 2.9.0.
I have already made some tries using your suggestion of calling test
function multiple times within withFixture method but I found two not
so good things about it:
1- Report tool only record test being called once and I have no way to
tell what drivers were tested.
2- When a test fail for one driver all other subsequent drivers will
be ignored (since exceptions are used to register failure).
Is my points correct?
About using shared tests I guess that is not the better solution since
tests would have to manually close (quit in my case) my resource
(webdrive), wouldn't they?
[1] http://code.google.com/p/selenium/wiki/GettingStarted
[2] http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebDriver.html
--
Fabio Cechinel Veronez
On Thu, Jun 16, 2011 at 11:52 AM, Fabio Cechinel Veronez
<fabio....@gmail.com> wrote:
> Hi Bill,
>
> Thanks for your prompt response, and yes, I'm Some("Fabio"). =P
>
> Well, when I say managed objects I mean objects like Input/Output
> Streams, java.sql.Connection, etc, which have 'close' method that
> should be called after using them.
>
> In my case I'm working with Selenium WebDrivers [1], which contain a
> method 'quit' that, from what i know, are expected to be called after
> each test. So, in this way, I have a new WebDriver for each test.
>
> WebDriver is the interface, and selenium provides one implementation
> of WebDriver for each browser it supports (IE, Firefox, Chrome..).
>
> So, my goal here is: write a test suite for a given web page and run
> it using a set of WebDriver implementations.
>
> Currently i'm using scala-test 1.6.1 and scala 2.9.0.
>
> I have already made some tries using your suggestion of calling test
> function multiple times within withFixture method but I found two not
> so good things about it:
>
> 1- Report tool only record test being called once and I have no way to
> tell what drivers were tested.
> 2- When a test fail for one driver all other subsequent drivers will
> be ignored (since exceptions are used to register failure).
>
> Is my points correct?
>
Yes, you're correct.
> About using shared tests I guess that is not the better solution since
> tests would have to manually close (quit in my case) my resource
> (webdrive), wouldn't they?
>
No I think that can be done via withFixture. I'll code up a quick
example to make sure.
Bill
class MyClassSpec extends WordSpec with MustMatchers {
"my object" when {
"doing this" must {
behave like goodObject { test =>
myObj = setupMyObject()
try {
test(myObj)
} finally {
myObj.close()
}
}
}
"doing that" must {
behave like goodObject { test =>
myObj = setupMyObject()
try {
myObj.doThat
test(myObj)
} finally {
myObj.close()
}
}
}
"being bad!" must {
behave like badObject { test =>
myObj = setupMyObject()
try {
myObj.doBad
test(myObj)
} finally {
myObj.close()
}
}
}
}
def goodObject(f: (MyObject => Unit) => Unit) {
"good behaviour 1" in { f((myObj) => myObj must be ('good)) }
"good behaviour 2" in { f((myObj) => myObj must not be ('bad)) }
}
def badObject(f: (MyObject => Unit) => Unit) {
"bad behaviour 1" in { f((myObj) => myObj must not be ('good)) }
"bad behaviour 2" in { f((myObj) => myObj must be ('bad)) }
}
}
--
Derek
Here's how I'd recommend you do this:
abstract class WebDriver {
private var quitHasBeenCalled = false
def quit() {
quitHasBeenCalled = true
}
override def toString = getClass.getName
}
class IEWebDriver extends WebDriver
class ChromeWebDriver extends WebDriver
class FirefoxWebDriver extends WebDriver
import org.scalatest.fixture.FixtureFunSuite
class WebDriverSuite extends FixtureFunSuite {
type FixtureParam = WebDriver
def withFixture(test: OneArgTest) {
// Extract browser name from the test name
val browserName = test.name.takeWhile(_ != ':')
// Create the appropriate driver for the browser
val webDriver = browserName match {
case "IE" => new IEWebDriver
case "Chrome" => new ChromeWebDriver
case "Firefox" => new FirefoxWebDriver
}
// Test with the driver fixture, ensuring it is cleaned up after
try {
test(webDriver)
}
finally {
webDriver.quit()
}
}
for (browser <- List("IE", "Chrome", "Firefox")) {
test(browser + ": test one") { driver =>
info("Testing using " + driver)
}
test(browser + ": test two") { driver =>
info("Testing using " + driver)
}
test(browser + ": test three") { driver =>
info("Testing using " + driver)
}
test(browser + ": test four") { driver =>
info("Testing using " + driver)
}
test(browser + ": test five") { driver =>
info("Testing using " + driver)
}
}
}
What I did is encode the browser name at the beginning of each test
name, using the for loop. So each pass through the for loop you
register a batch of tests for one browser. But the driver will be
passed to each test. To make sure it passed the appropriate driver,
withFixture extracts the browser name from the front of the test name,
then creates the appropriate driver, and passes that into the test
function. That way you get one of each test you write per browser.
When I run this from the interpreter it looks like:
setups-MacBook-Pro-2:sharedt bv$ scala -cp
.:scalatest-1.6.1/scalatest-1.6.1.jar
Welcome to Scala version 2.9.0.final (Java HotSpot(TM) 64-Bit Server
VM, Java 1.6.0_24).
Type in expressions to have them evaluated.
Type :help for more information.
scala> import org.scalatest._
import org.scalatest._
scala> run(new WebDriverSuite)
WebDriverSuite:
- IE: test one
+ Testing using IEWebDriver
- IE: test two
+ Testing using IEWebDriver
- IE: test three
+ Testing using IEWebDriver
- IE: test four
+ Testing using IEWebDriver
- IE: test five
+ Testing using IEWebDriver
- Chrome: test one
+ Testing using ChromeWebDriver
- Chrome: test two
+ Testing using ChromeWebDriver
- Chrome: test three
+ Testing using ChromeWebDriver
- Chrome: test four
+ Testing using ChromeWebDriver
- Chrome: test five
+ Testing using ChromeWebDriver
- Firefox: test one
+ Testing using FirefoxWebDriver
- Firefox: test two
+ Testing using FirefoxWebDriver
- Firefox: test three
+ Testing using FirefoxWebDriver
- Firefox: test four
+ Testing using FirefoxWebDriver
- Firefox: test five
+ Testing using FirefoxWebDriver
Let me know if you have any questions or concerns about this approach.
By the way in the process of answering your question I found a bug in
my shared tests example that I think came in at Scala 2.8. I need to
change +: to +=: in push in the Stack class.
Bill
Thank you very much.
Very interesting this approach of sending information encoded at test's name.
Is there any other way to send this king of information? Maybe using configMap.
Btw, is there any reason why test's tags info are not present at OneArgTest?
On Thu, Jun 16, 2011 at 1:32 PM, Fabio Cechinel Veronez
<fabio....@gmail.com> wrote:
> Hello Bill,
>
> Thank you very much.
>
> Very interesting this approach of sending information encoded at test's name.
>
Test names all have to be unique in a ScalaTest suite, and to make
them unique when using shared tests you need to encode something about
the fixture in there anyway. So may as well pull it out in withFixture
in your case.
> Is there any other way to send this king of information? Maybe using configMap.
>
The configMap passed to withFixture is done by runTest, so if you
override runTest you could also add things to the configMap before you
pass it into withFixture. But that would be a bit of work.
> Btw, is there any reason why test's tags info are not present at OneArgTest?
>
Just that my intention for tags was to allow filtering of tests to run
and not run. So once a test survives filtering, withFixture would be
called and it should probably just run the test. If you want to use a
test's tags in withFixture, though, you could do so by calling tags
and looking up the test's tags by its test name (which is passed to
withFixture).
--
You received this message because you are subscribed to the Google
Groups "scalatest-users" group.
To post to this group, send email to scalate...@googlegroups.com
To unsubscribe from this group, send email to
scalatest-use...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/scalatest-users?hl=en
ScalaTest itself, and documentation, is available here:
http://www.artima.com/scalatest
---
You received this message because you are subscribed to the Google Groups "scalatest-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalatest-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups "scalatest-users" group.
To post to this group, send email to scalate...@googlegroups.com
To unsubscribe from this group, send email to
scalatest-use...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/scalatest-users?hl=en
ScalaTest itself, and documentation, is available here:
http://www.artima.com/scalatest
---
You received this message because you are subscribed to the Google Groups "scalatest-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalatest-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I find that if I use a trait instead of a class, the BeforeAndAfterAll () cases gets ran twice:
trait AuthenticatorSuites extends FlatSpecLike with BeforeAndAfterAll with Matchers{this: Suite =>override def beforeAll() {Logger.debug("AuthenticatorSuites before")super.beforeAll()}override def afterAll() {super.afterAll()Logger.debug("AuthenticatorSuites after")}behavior of "test"it should "see this test " in {1 shouldBe (1)}it should "als see this test" in {"Jack" shouldEqual ("Jack")}}@RunWith(classOf[JUnitRunner])class AuthenticatorOne extends AuthenticatorSuites {Logger.info("trace")}
--
You received this message because you are subscribed to the Google
Groups "scalatest-users" group.
--