What's Meteor's story with respect to unit testing?
The example videos look great for building prototypes but I haven't seen any indication of how to write tests for it.
For testing meteor packages, see Tinytest.
The testing story as a whole is captured on the official Trello board.
Take a look at documentation of Laika testing framework :
http://arunoda.github.io/laika/
Screencast with introduction to Laika done by its creator - Arunoda Susiripal:
http://www.discovermeteor.com/2013/06/06/testing-meteor-apps-with-laika
My guess is that you would use velocity + jasmine-unit packages.
Velocity had been selected as the official testing framework for meteor 1.0. The announcement has been made in the last meteor devshop (june 2014).
Packages developed with velocity:
velocity (the test runner)
jasmine-unit (jasmine syntax)
mocha-web-velocity (for testing collections)
velocity-html-reporter (view the tests in the browser)
About the usage of tinytest, once you have watched the screencast proposed by Jeff Foster, and understood the idea, you may want to take a look at the APIS of both tinytest and test-helpers packages.
For now the only documentation available for tinytest is at the bottom of the tinytest.js file
https://github.com/meteor/meteor/blob/devel/packages/tinytest/tinytest.js
The list of the helpers made available by the test-helpers package can be looked at here: https://github.com/meteor/meteor/tree/devel/packages/test-helpers. There often is some documentation inside each file.
Digging in the existing tests of meteor's packages will provide lot of examples. One way of doing this is to make a search for Tinytest. or test. in the package directory of meteor's source code
Related
Do we have any unit testing frameworks in Vapor?
I am looking dependencies/framework which will help to do the Unit testing some of my web services and methods in easyway.
I've tried following solutions.
http://seatoncode.com/unit-testing-vapor/
https://medium.com/#tullio.sebastiani/unit-testing-vapor-toolbox-v-1-0-1-projects-c59a056c3b9b#.qf0kl1pfo
Regarding testing frameworks, I'm quite happy with Apple's XCTest, but if you're looking for something different, I recommend Quick.
If you also want to test the front-end, there are several solutions out there, and choosing one, in my opinion, depends on what front-end framework you pick, if any.
Anyway, I see you found articles on how to configure Vapor for testing. In this post I do something similar, but also I made a template to create new apps already set for testing. You can find it here.
What are the current options for testing custom-built Meteor packages? Is there anything out there other than the built-in TinyTest?
Found this question from a year ago, but my question is specifically about testing Meteor packages, not your core app.
Has anyone used Laika for testing their own packages?
Meteor's testing support is quite in flux at the moment (June 2014). I imagine most people will stick with Tinytest until the community develops a better solution that supports better UI tests and end-to-end tests.
https://github.com/xolvio/velocity is trying to unify a bunch of testing frameworks to have Meteor support. You may want to check out their progress at https://groups.google.com/forum/#!forum/velocity-core.
Velocity is now the officially sanctioned testing framework for Meteor, and there's a book about it - Meteor Testing.
I am currently looking into the meteor framework and this question immediately jumps to mind.
Is code which I write (for example Template.xxx code or Template.xxx.events) actually testable in any way?
Of course you can test code which is not bound to the meteor runtime as you would any other code, but my impression is that most code you will write inside of meteor is somehow scoped to meteor and its functions.
There doesn't seem to be any official test framework yet apart from the undocumented Tinytest (see the video tutorial) and its helpers, but you can always stub/mock out the Meteor framework API like I've done in this trivial example on github.
I imagine it could get a lot harder for non-trivial applications, so it's probably a good idea to separate core application logic away from Meteor API calls.
As of February 2014, Meteor code is unit-testable using the built-in Tinytest framework, as long as you move all your application code into packages, which you should do anyway. The quick-and-dirty way amounts to adding a package.js file. That file serves to:
Declare your exports. It's good practice for clean namespacing to have one global object for your app
Declare your test files
Here is an example by Eventedmind - https://github.com/EventedMind/meteor-file
You can see in meteor-file-test.js that it accesses MeteorFile, which is declared as an export in package.js.
I think it is testable although I haven't looked into it too deeply.
If you open up the liveui package ($METEOR_HOME/packages/liveui) there seems to be quite a few unit tests written using TinyTest and testing the rendering. I think that would be a good place to start:-
liveui_tests.js
liveui_tests.html
etc.
Hope that helps
I've created a blog post here showing how to do effective unit testing in Meteor, along with an example project on GitHub. Hope it helps.
http://blog.xolv.io/2013/04/unit-testing-with-meteor.html
Velocity has been selected as the official testing framework for meteor 1.0. The announcement has been made in the last meteor devshop (june 2014).
Packages developed with velocity:
velocity (the test runner)
jasmine-unit (jasmine syntax)
mocha-web-velocity (for testing collections)
velocity-html-reporter (view the tests in the browser)
Although tools like RUnit, svUnit, and testthat are good for package developers, I think it would be useful to have some means of uploading test scripts or even just usage examples for particular packages. Users who do continuous integration (e.g. Jenkins) or even basic unit testing may already have such tests and could find it beneficial to contribute scripts for package maintainers' use.
Does such functionality exist, either through CRAN or RForge, or via other sites, such as github? If so, is there a major example of using a repository, e.g. github, to allow users to contribute tests?
(Thanks to #mariotomo for reminding me of svUnit.)
I would suggest to refrain from overcomplicating things. Why not just something like this:
Look at a given package's sources (ie on r-forge, rforge, github, ... or straight CRAN sources),
understand its testings scheme (ie tests/ directory, examples in manual pages, or one of the three unit testing frameworks from CRAN), and
contribute new tests.
That's really all there is too it. Same for contributing documentation, demo scripts, new code, .... We can and should focus on the open in open source.
By backend I mean software systems that consume data, process files or communicate using machine interfaces (REST, SOAP, CORBA, etc...). No fancy web or UI testing is necessary. I have in mind Cucumber and Robotframework but I don't know how well suited they are in the task at hand.
There isn't an easy answer to this question.
Sounds like you got your domain right... because if you were trying to test UI/Web components acceptance testing frameworks make not be the right tool for the job.
You have a few options
SpecFlow
Cucumber
StoryTeller
FitNesse
mSpec
a few others.
I'm partial to StoryTeller & mSpec.. but each of these tools have their pros/cons.
Questions you should be asking yourself (and your team are)
Who is going to be writing/maintaining the tests?
Are self documenting acceptance tests provide value for your organization?
Which technology would integrate most easily with your current build process?
I have used Cucumber to test a batch application written in perl and plsql, an informatica transformation, and am currently using it to test a telephony ivr/queueing system. Ruby provided the gems I needed to drive the system and it was very easy for the testers to learn the language/syntax.
If it comes to Robot Framework I have an experience with bad support in Intellij for this. I'm using IntelliBot plugin. In many cases you will know your mistake like wrong syntax, cannot find keyword etc. late in test runtime.
Problems with finding imported libraries, no debug, no simple refactor like rename keyword across a project.