I recently created a Meteor package and want to write some tests. What my test package basically do is that users can insert into the template {{> abc}} and they'll get an HTML element printed on the page.
With TinyTest, all you can do is test the package's API using something like test.equal(actual, expected, message, not). However, I need it to test whether the element was successfully printed on the page. Furthermore, I will pass the template some parameters and test them too.
It seems like I'd have to create a dummy app, run bash to initiate the app, and test whether the elements can be found on page. So should I only use TinyTest to test the API, and write my own tests (somehow!) for templating? If not, how should I go about it?
I read something about Blaze.toHTML, but I cannot find anything in the documentation on it? Nor it's source page.
I think TinyTest is great for starting with Unit testing, but what you need sounds more like an Integration test.
I would recommend you look into the following links for more info on testing with Meteor, especially with Velocity - Meteor's official testing framework:
Announcing Velocity: the official testing framework for Meteor applications
Velocity
The Meteor Testing Manual
You can create a demo application, and run integration tests using Mocha or Jasmine.
Related
I have recently upgraded to version 1.0.0 from 0.9.6 and noticed that the generated karate-summary.html file, it doesn't display all the tested feature files in the JUnit 5 Runner unlike in 0.9.6.
What it displays instead was the last tested feature file only.
The below screenshots are from the provided SampleTest.java sample code (excluding other Tests for simplicity).
package karate;
import com.intuit.karate.junit5.Karate;
class SampleTest {
#Karate.Test
Karate testSample() {
return Karate.run("sample").relativeTo(getClass());
}
#Karate.Test
Karate testTags() {
return Karate.run("tags").relativeTo(getClass());
}
}
This is from Version 0.9.6.
And this one is from Version 1.0.0
However, when running the test below in 1.0.0, all the features are displayed in the summary correctly.
#Karate.Test
Karate testAll() {
return Karate.run().relativeTo(getClass());
}
Would anyone be kind to confirm if they are getting the similar result? It would be very much appreciated.
What it displays instead was the last tested feature file only.
This is because for each time you run a JUnit method, the reports directory is backed up by default. Look for other directories called target/karate-reports-<timestamp> and you may find your reports there. So maybe what is happening is that you have multiple JUnit tests that are all running, so you see this behavior. You may be able to over-ride this behavior by calling the method: .backupReportDir(false) on the builder. But I think it may not still work - because the JUnit runner has changed a little bit. It is designed to run one method at a time, when you are in local / dev-mode.
So the JUnit runner is just a convenience. You should use the Runner class / builder for CI execution, and when you want to run multiple tests and see them in one report: https://stackoverflow.com/a/65578167/143475
Here is an example: ExamplesTest.java
But in case there is a bug in the JUnit runner (which is quite possible) please follow the process and help the project developers replicate and then fix the issue to release as soon as possible.
In one vein of thought I would like to configure a build with a custom task that will serve instead of the test default task. I will not be registering it as an "sbt test framework" as I'd like to avoid the syntax, limitations and history that comes with that. For example I'd like more flexibility in formatting, storing and sending test results.
Would it be possible introducing an sbt task to mimic sbt's default test task, in the following essential senses:
depend on compilation
be a dependency for other tasks such as artifact publishing tasks, and have them depend on a success return value from it
be able to provide it with library dependencies which will be excluded from final publishable artifacts
be able to control it just like any other task dependency
etc
Alternatively, are you able to delineate the structure of the mostly undocumented sbt TestFramework interface to a level that it's straightforward having your own formatting, test output logic, and test results publishing code, in your TestFramework implementation? I have mostly failed locating scalaTest's implementation of it.
Thanks in advance for you answers on both techniques.
I'm using Velocity with the mike:mocha framework and the chai assertions. Everything is working great, but when it comes time to do stubbing, mocking and spying, I've hit a bit of a roadblock. These aren't core features of mike:mocha or chai, so I found practicalmeteor:chai, which should/may have added spies.
My first stab at finding out whether this is true was to write the following code:
it 'calls update when both documents are present but different', ->
spies.create('log', console, 'log')
which gives me:
ReferenceError: spies is not defined
at packages/velocity:test-proxy/tests/mocha/server/charger_server_doc_spec.coffee:88:9
at wrappedFunc (packages/mike:mocha/server.js:200:1)
at runWithEnvironment (packages/mike:mocha/server.js:156:1)
That implies to me that I've misunderstood what practicalmeteor:chai provides, however, the code I showed in the first example is copied verbatim from the README.
Question: Any tips on getting this to work? Is it a load order issue? The code on Github shows spies and so on are implemented in this package. So I'm a bit stuck.
Thanks!
The package practicalmeteor:chai does not include the practicalmeteor:sinon package which is required to get the spies API included.
They are separate packages because you may not have to use spies when creating basic tests with chai.
If you look at the package.js file in the practicalmeteor:chai package, it does not include the sinon files.
So, just running meteor add practicalmeteor:sinon should solve your problem.
We are looking forward to using squashTA to manage our tests. The problem we are facing is that we already have a big automated tests collection and aren't able to make them run via squash TM using squash TA.
Our tests are using junit+selenium WebDriver+SpringFramework.
Currently, we launch our automated tests via maven (in commandLine), and we have a jenkins server running them regularly.
We tried to reuse our tests in a squash TA project, putting them in src/squashta/resources/selenium/java
But code in this folder doesn't even support java packages. It's like the java in the example isn't real java but a fake java parse by squashTA.
Is there any mean of using such already existing tests with squash(TA/TM) ?
Or, any alternatives you know that could do the job ? (we are currently using testlink and must change).
If your selenium test is in :
src/squashTA/resources/selenium-test/src/main/java/org/squashtest/ta/selenium/PetStoreTest.java
With a such structure, the test automation script to run the selenium test (which is in the package org.squashtest.ta.selenium) is :
TEST :
LOAD selenium-test/src/test AS seleniumTestSource
CONVERT seleniumTestSource TO script.java(compile) AS seleniumTestCompiled
CONVERT seleniumTestCompiled TO script.java.selenium2(script) USING $(org.squashtest.ta.selenium.PetStoreTest) AS seleniumTest
EXECUTE execute WITH seleniumTest AS seleniumResult
ASSERT seleniumResult IS success
If your selenium test has some dependencies to other libraries (like to spring in your case), you have to add those depencencies as dependency of the squash-ta-maven-plugin in the pom.xml of your Squash TA project
I need to be able to perform all of the available functions that the Package Manager Console performs for code first DB migrations. Does anyone know how I could accomplish these commands strictly through user defined code? I am trying to automate this whole migration process and my team has hit the dreaded issue of getting the migrations out of sync due to the number of developers on this project. I want to write a project that the developer can interact with that will create and if need be rescaffold their migrations for them automatically.
PM is invoking through PowerShell and PS cmdlets (like for active directory etc.)
http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference
The Package Manager Console is a PowerShell console within Visual
Studio
...there is essentially very little info about this - I've tried that before on couple occasions and it gets down to doing some 'dirty work' if you really need it (not really sure, it might not be that difficult - providing you have some PS experience)
Here are similar questions / answers - working out the PS comdlets is pretty involving - in this case it has some additional steps involved. And PS tends to get very version dependent - so you need to check this for the specific EF/CF you're using.
Run entityframework cmdlets from my code
Possible to add migration using EF DbMigrator
And you may want to look at the source code for EF that does Add-Migration
(correction: this is the link to official repository - thanks to #Brice for that)
http://entityframework.codeplex.com/SourceControl/changeset/view/f986cb32d0a3#src/EntityFramework.PowerShell/Migrations/AddMigrationCommand.cs
http://entityframework.codeplex.com/SourceControl/BrowseLatest
(PM errors also suggest the origins of the code doing the Add-Migrations to be the 'System.Data.Entity.Migrations.Design.ToolingFacade')
If you need 'just' an Update - you could try using the DbMigrator.Update (this guy gave it a try http://joshmouch.wordpress.com/2012/04/22/entity-framework-code-first-migrations-executing-migrations-using-code-not-powershell-commands/) - but I'm not sure how relevant is that to you, I doubt it.
The scaffolding is the real problem (Add-Migration) which to my knowledge isn't accessible from C# directly via EF/CF framework.
Note: - based on the code in (http://entityframework.codeplex.com/SourceControl/changeset/view/f986cb32d0a3#src/EntityFramework.PowerShell/Migrations/AddMigrationCommand.cs) - and as the EF guru mentioned himself - that part of the code is calling into the System.Data.Entity.Migrations.Design library - which does most of the stuff. If it's possible to reference that one and actually repeat what AddMigrationCommand is doing - then there might not be a need for PowerShell at all. But I'm suspecting it's not that straight-forward, with possible 'internal' calls invisible to outside callers etc.
At least as of this post, you can directly access the System.Data.Entity.Migrations.Design.MigrationScaffolder class and directly call the Scaffold() methods on it, which will return you an object that contains the contents of the "regular" .cs file, the "Designer.cs" file and the .resx file.
What you do with those files is up to you!
Personally, I'm attempting to turn this into a tool that will be able to create EF6 migrations on a new ASPNET5/DNX project, which is not supported by the powershell commands.