Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You can add custom test tags in build.scala. Here's the sample code from one of my projects. Keep in mind, you don't have to bind it to it:test. You could name it anything you want.</p> <pre><code>lazy val AcceptanceTest = config("acc") extend(Test) lazy val Kernel = Project( id = "kernel", base = file("."), settings = defaultSettings ++ AkkaKernelPlugin.distSettings ++ Seq( libraryDependencies ++= Dependencies.Kernel, distJvmOptions in Dist := "-Xms256M -Xmx2048M", outputDirectory in Dist := file("target/dist"), distMainClass in Dist := "akka.kernel.Main system.SystemKernel" ) ).configs(AcceptanceTest) .settings(inConfig(AcceptanceTest)(Defaults.testTasks): _*) .settings(testOptions in AcceptanceTest := Seq(Tests.Argument("-n", "AcceptanceTest"), Tests.Argument("-oD"))) </code></pre> <p>Just pay attention to the lazy val at the top and the .configs part.</p> <p>With that setup, when I type acc:test, it runs all tests with the AcceptanceTestTag. And you can just boot the server as part of what gets called by your test suite. Can even tag tests by needing server and not needing it so you can separate them once your suite gets big and takes longer to run.</p> <p>Edit: Added to respond to comments.</p> <p>To Tag tests, create a tag like this</p> <pre><code>import org.scalatest.Tag object AcceptanceTest extends Tag("AcceptanceTest") </code></pre> <p>then put it here in your tests...</p> <pre><code>it("should allow any actor to subscribe to any channel", AcceptanceTest) { </code></pre> <p>And that cooresponds to the same build setup above. Only tests with That tag will be run when I call acc:test.</p> <p>What came to mind for your problem was the solution I use for that same situation. Right now, you're doing the work in build.scala. I'm not sure if it's possible to do what you're saying right there... but what I do does the same thing but a bit differently. I have a trait that I mix-in to all tests that need a vagrant server. And I tag the tests that use it as VagrantTest.</p> <p>And it works like a singleton. If one or more tests need it, it boots. But it will only boot one and all tests use it. </p> <p>You could try doing the same, but over-ride it:test in the config file. Instead of "acc" in the example above, put "it". If that's not quite what you're looking for, may have to see if anyone else pops in.</p> <p>So, basically when I call it:test it accesses running all tests with IntegrationTest test tag on it (as well as those with VagrantTest and a few others). So all the longer-running server tests don't get run as much (takes too long).</p>
    singulars
    1. This table or related slice is empty.
    1. POSBT: how to modify it:test with a task that calls the original test task?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USDante Romero
    1. USDante Romero
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COah, thanks for the answer. How do you tag your tests? that sounds like an interesting idea.
      singulars
      1. PO
      1. USLee Mighdoll
    2. COI understand that I can use a new key or a key in different scope. The original question uses a new key in the same config, and your example uses a key in different scope. But the question here is whether it's possible to use the same key (test) in the same config scope (it). I think it would be nice if my users could re-use what they know from other builds on how to run integration tests w/o having to remember something new for this one.
      singulars
      1. PO
      1. USLee Mighdoll
    3. CO+1 for explaining how to tag tests
      singulars
      1. PO
      1. USLee Mighdoll
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload