I'm learning Ember basics running the code online in the awesome http://ember.jsbin.com/ code fiddling service. It provides a basic boilerplate of an HTML file, a CSS file and a JS file.
I wonder how can use it to run unit tests of my Ember app.
My goal is to be able to run the app and the tests from a single JSBin instance. I imagine switching between the two modes by adding/removing ?test in the URL, or something like that.
Yeah it's highly unlikely that this will work. Unit tests should be run by cmd.
Okay, i gave it another try and found that official Ember Guides contain a demo of how it can be done in JSBin.com!
Demo: http://jsbin.com/jesuyeri/20/edit?js,output
Relevant guides page: http://emberjs.com/guides/testing/test-helpers/
Related
I am at the beginning of my adventure with Dart, do please be kind :)
I found some answers related to minifying JS files made from Dart (dart2js), but I cannot find any info about minifying Dart code itself.
Is there any plan to do this?
For JS there are some tools i.e. YUI Compressor.
I think Dart need also such application.
--
Best regards,
Tom
You can use dart2js with the --output-type=dart to output Dart code instead of JavaScript. Coupled with the --minify option you will get a minified dart file.
Looking at the dart tools page: https://www.dartlang.org/docs/dart-up-and-running/contents/ch04-tools-dart2js.html
There are a few things that are perhaps relevant:
--output-type=dart
Output Dart code instead of JavaScript. This option is useful when deploying your app, because it generates a single file
containing everything the app needs.
And tree-shaking removes unused code:
Don’t worry about the size of your app’s included libraries. Thanks to a feature called tree shaking, dart2js omits unused classes, functions, methods, and so on. Just import the libraries you need, and let dart2js get rid of what you don’t need.
Don't know if browser can load snapshot, and never tried. But if so, could fit your needs: https://www.dartlang.org/articles/snapshots/
I'm trying to get set up with unit tests for google app scripts, and I found two projects:
https://code.google.com/p/gas-unit/
https://code.google.com/p/gasunit/
So I'm confused which to use :-)
I just had a go with the unhyphenated gasunit, which seems to expect that the script is embedded in a spreadsheet, which I am a little unclear on how to do ... and the scripts I want to test are web based scripts rather than spreadsheet ones
I had more luck testing the hyphenated gas-unit, which managed to send me both an email output of the test and generate a results page in my google site:
https://sites.google.com/site/testappscript2/TestResults
so I'm going to with gas-unit for the moment, but I'd really like to see some official testing framework incorporated by Google. In particular I'd like to find some way to get these scripts to be run with some frequency to send me the results. Also I'd love to get some BDD going; see my other posts:
How to get Cucumber/Capybara/Mechanize to work against external non-rails site
how to use capybara has_text
Come on Google, you famously have "Testing Rocks, Debugging Sucks" in all your bathrooms? How about better testing support for Google Apps Scripts?
You can try out QUnit for Google Apps Script. It is a patch for QUnit turned into a Google Apps Script library with API docs.
All you need is a script project that imports a QUnit library (for example the one with the project key MxL38OxqIK-B73jyDTvCe-OBao7QLBR4j) and has a doGet function that configures QUnit using URL parameters and optionally also with your own settings, loads a function that runs your tests, and finally returns QUnit.getHtml(). Here is an example:
function doGet( e ) {
QUnit.urlParams( e.parameter );
QUnit.config({ title: "Unit tests for my project" });
QUnit.load( myTests );
return QUnit.getHtml();
};
// Imports the following functions:
// ok, equal, notEqual, deepEqual, notDeepEqual, strictEqual,
// notStrictEqual, throws, module, test, asyncTest, expect
QUnit.helpers(this);
function myTests() {
module("dummy module");
test("dummy test", 1, function() {
ok(true);
});
}
Then authorize the script, save a version of it, publish the script project ("Deploy as web app") and go to the test URL ("latest code") with your browser. Your tests will be run and results will be displayed via HtmlService. You can single-click on them to see their assertions, but as of writing this, you will probably not be able to do so in Firefox 20 and 21 due to Caja issue 1688.
I just wrote another testing framework named GasT for my google spreadsheet add-on development & testing.
GasT is a TAP-compliant testing framework for Google Apps Script. It provides a simple way to verify that the GAS programs you write behave as expected. https://github.com/huan/gast
My goal is to get a simple tap tool like tape(for javascript) or bats(for bash). the test suite format is quite clear:
var gastLibUrl = 'https://raw.githubusercontent.com/zixia/gast/master/src/gas-tap-lib.js'
eval(UrlFetchApp.fetch(gastLibUrl).getContentText())
var test = GasTap.setPrintDriver('Logger')
function gast() {
test('do calculation right', function (t) {
var i = 3 + 4
t.equal(i, 7, 'I can calc 3 + 4 = 7')
})
test('Spreadsheet exist', function (t) {
var ss = SpreadsheetApp.openById('1TBJpvlW3WWney4rk1yW5N9bAP8dOMkWxI97dOtco-fc')
t.ok(ss, 'I can open spreadsheet')
})
test.finish()
}
Hope someone will like it. :)
there's a online version, you can go to have a look on it here: https://docs.google.com/spreadsheets/d/19M2DY3hunU6tDQFX5buJmZ_f3E8VFmlqAtodyC-J8Ag/edit#gid=0&vpid=A1
The clasp tool provides the ability to develop and deploy Apps Script projects locally from the command-line.
From the clasp repo:
npm install -g #google/clasp
enable Apps Script API: https://script.google.com/home/usersettings
Develop locally and use the clasp tool to deploy.
Edit the node-google-apps-script project has been deprecated in favor of clasp
There is the node-google-apps-script package to allow using standard JavaScript packages and automated testing tooling.
npm install -g node-google-apps-script.
Go through the authorization steps to provide client secrets to allow uploading and importing Apps Script projects.
Use gulp or grunt or whatever you use for test running normal JavaScript projects.
There is an official Google sample available that uses this workflow.
See Google Apps Developer Blog post announcement for more details.
Once the files are downloaded, convert them to TypeScript by renaming them to end with .ts instead of .js. Once they are TypeScript, ava can be used to test them. Converting them to TypeScript also lets one use ES6 language features.
I created gas-unit (https://code.google.com/p/gas-unit/) and have spent a bit of time over the last few days tidying up the examples and adding a HTML test runner.
I have been using it myself for some spreadsheet manipulation I've been doing with reasonable success. I've also been using Jasmine for non-GAS client side js work and have really enjoyed that. I miss the ability in gas-unit to easily create spys and I favour the BDD style of specification writing.
gas-unit has been a great learning exercise for me and it does work although there may be undiscovered issues with scope and closure - this is my first significant js exercise outside of DOM manipulation.
I think the future for testing in GAS has to be with a port of QUnit (as Adam suggests) or Jasmine. I had a quick look at what it would take to port Jasmine but as yet have not been able to find the time to tackle it.
Check out QUnitGS2 - a new Apps Script library using the latest version of QUnit (v2.10.1).
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)
Any best way to run the jasmine HTML reporter with browserify styled code? I also want to be able to run this headless with phantomjs, thus the need for the HTML reporter.
I've created a detailed example project which addresses the jasmine testing (and others) - see https://github.com/amitayd/grunt-browserify-jasmine-node-example. Discussion at my blog post
The approach in this aspect was to create a Browserify bundle for the main source code (where all the modules are exposed), and one for tests which relies on external for the main source code. Then tests can be run both in PhantomJS or a real browser.
I don't think there's a jasmine-browserify package yet, and it doesn't really match Browserify/NPM's way of doing things (avoid global exports).
For now, I just include /node_modules/jasmine-reporters/ext/jasmine.js and jasmine-html.js at the top of my <head>, and require all my specs in a top-level spec_entry.js that I then use as the entry point for a Browserify bundle that I put right afterwards in the <head>. (Note that if the entry point is not top-level, you'll have a bad time due to a long-lasting, gnarly bug in Browserify).
This plays nicely with jasmine-node as long as you don't assume the presence of a global document or window. However, you do have to remember to register your specs in that spec_entry.js, unless you want to hack Browserify to get it to crawl your directories for .spec.js files.
I'd be very interested in a more elegant solution, though, that would transparently work with jasmine-node and browserify.
If you use grunt-watchify, no need to create spec_entry.js. Just use require in your specs, and then bundle your specs with grunt-watchify:
watchify: {
test: {
src: './spec/**/*Spec.js',
dest: 'spec/spec-bundle.js'
}
},
jasmine: {
test: {
options: {
specs: 'spec/spec-bundle.js'
}
}
},
Then run your tests with
grunt.registerTask('test', ['watchify:test','jasmine:test']);
As all above answers are little outdated (of course it doesn't mean that they are not working any more etc.) I would like to point to https://github.com/nikku/karma-browserify this is a preprocessor for karma runner. It combines test files with all required dependencies. Such created browserify bundle is passed to karma which base on configuration runs it. Please be aware that you can choose any modern test framework (jasmin,mocha...) and browsers (phantom, chrome ..) Probably this is exactly what you need :)
You may also want to look into Karma. It really simple to setup and it will watch for changes and rerun your test. Check out this sample project that uses Karma to test a browserify/react project. You just need to add a few dependancies and create a karma.conf.js file.
https://github.com/TYRONEMICHAEL/react-component-boilerplate
I am Unit testing on the client side of a GWT+SmartGWT application.
First I tested with GwtTestCase. Too long for unit testing a huge application. GwtTestSuite doesn't help. It still takes too much time to execute. (more, it asked me to start a browser when it's testing)
Then gwt-test-utils : Great framework. Sadly, my javassist version is 3.5 and need at least the 3.11. Javassist is used by gilead so I can't touch this. So, no gwt-test-utils...
I saw Selenium. That's just great. With htmlunit driver, it's fast and useful. Simplest way to test a webapp. Problem here is SmartGWT generates it's own IDs when it generates the web page. So I can't get the TextItems and fill them since those IDs are constantly changing. I found that it could be solved by using setID() before the initialization of the widget. But that's the ID of the scLocator and not an HTML ID. Selenium doesn't want to work with scLocator.
=> Is there a simple way to accept scLocator with Selenium ?
(And when I say simple, it must be simple... I'm not a specialist in Java...)
Could someone help me to unit test the application ? It's coded in Java, it's huge and I have to cover ~70% of the code (25k lines of code)
Some more specs :
Maven is used to compile.
I'm not touching at the server side.
Tests must be faster than GwtTestCase and Suite :/
I hope my problem is clear, I'm not a native english so sorry for mistakes I may do :x
We provide Selenium extensions and a user guide for them in the SDK, under the "selenium" directory at top level.
If you download 3.1d (from smartclient.com/builds) there's even more documentation including some samples for JUnit.
Do not use ensureDebugId() (won't have an effect at all). Never try to work with DOM IDs (won't work).
Best practices information in the Selenium user guide explains when you should use setID().
I found that it could be solved by using setID() before the
initialization of the widget. But that's the ID of the scLocator and
not an HTML ID.
Why don't you try:
widget.ensureDebugId("some-id");
From the Java docs for ensureDebugId():
Ensure that the main Element for this UIObject has an ID property set,
which allows it to integrate with third-party libraries and test tools
< defaultUserExtensionsEnabled>true< /defaultUserExtensionsEnabled>
< userExtensions>[path to user-extensions.js]< /userExtensions>
There we go. I managed to make it work. (With the selenium-maven-plugin in the < configuration> tag)
Thanks for your help though.