I have been trying to incorporate Jasmine Test descriptions in my Enyo Applications. Is there any standard way to do this ?
Edit: Forgive me, I should ask for A workable way instead of a "standard" way. Neither of the sites have enough docs on this thing.
Typically, you'll only be testing your models and other such non-UI logic with Jasmine. What you'll want to do is create a test suite that loads Jasmine and the Enyo framework. Then, in your tests you'll create the necessary Enyo objects on the fly. The Enyo team uses Mocha for our testing and you can take a look at the enyo/tools/mocha-tests directory to see how we incorporated unit tests for the framework.
For UI testing you'll want to look at something like Nightwatch or WD.js
I know how to use Tinytest to test a package, also how to view its results on the console rather than in the webapp at localhost:3000 but I'd like to functionally test a Meteor app that's not really suitable to be made into a package. How can I do that? Or must I use RTD or the new Velocity?
Hi Dan — I think RTD is the best option at the moment — we're writing a book about testing meteor (http://testingmeteor.com/) and will likely develop our own approach in the course of that effort. In particular, we want a cucumber/gherkin layer for BDD that doesn't seem to exist yet.
Ben Green has published the Tinytest In App Meteor package. It does not use Velocity, so you must clean up after yourself, but you avoid the paradox of choice and can get on with writing tests.
There's also a numtel:velocity-tinytest package to use Velocity with Tinytest in your app.
I've been playing around with Angular the past week or so learning its ins and outs. I am now at a point where I'm trying to figure out the best way to restructure my app to do E2E testing, given that it will be embedded into a preexisting site, rather than stand on its own.
The problem comes in how to handle index.html from the angular-seed project, since my understanding is that Karma needs to point itself via scenarios.js at something in order to load and bootstrap the app before testing.
The markup currently in index.html will need to be inserted into the larger HTML structure of my page when it is being put together by our servers. There is no further preprocessing that must be done to the top-level Angular template, but this seems to be enough to complicate the testing process considerably.
This leaves me with three options as far as I can tell for enabling E2E testing:
1) duplicate the index.html code in its entirety to keep around as a complete mockup for testing
2) use a single angular route and ngView to access my top level view template (reducing the test purposes index.html to little more than <ng-view></ng-view> and <script> tags)
3) fold and just use Selenium for high-level testing
The first option introduces a maintainability problem, and the second is undesirable because it limits the testability of any aspect of the app outside the <ng-view>. Not an issue now, but could be as the app grows. And three, well, I've heard Selenium creates a lot of headaches with Angular apps that are best avoided by using the purpose-built Angular E2E testing tools.
So how is this situation typically handled?
I am quite new to Grails, but I am using this plugin for functional testing:
http://www.grails.org/Grails%20Functional%20Testing
I am wondering how to inject a service such as the messageSource or or the applicationContext so I can have access to different resources. A simple example would be that I want to write a functional test to check if the text on the website is equal to the message string in the messages.properties file. Right now I cant seem to find an out of the box way of doing that. Can you advice on something? Also is that the best functional testing framework for grails since its quite limited?
You may want to try Geb instead it is a good framework that has nice support and good docs. But the one items to remember is that functional tests are running against the full stack so some tests you may find work better as integration or unit tests.
You can use the remote control plugin in grails to modify your grails application on the fly. It uses the groovy remote control mechanism and serializes results for functional tests
I have been writing tests for my Ruby code for a while, but as a frontend developer I am obviously interested in bring this into the code I write for my frontend code. There is quite a few different options which I have been playing around with:
CasperJS
Capybara & Rspec
Jasmine
Cucumber or just Rspec
What are people using for testing? And further than that what do people test? Just JavaScript? Links? Forms? Hardcoded content?
Any thoughts would be greatly appreciated.
I had the same questions a few months ago and, after talking to many developers and doing a lot of research, this is what I found out. You should unit test your JavaScript, write a small set of UI integration tests and avoid record and playback testing tools. Let me explain that in more detail.
First, consider the test pyramid. This is a interesting analogy created by Mike Cohn that will help you decide which kind of testing you should be doing. At the bottom of the pyramid are the unit tests, which are solid and provide fast feedback. These should be the foundation of your test strategy and thus occupy the largest part of the pyramid. At the top, you have the UI tests. Those are the tests that interact with your UI directly, like Selenium does for example. Although these tests might help you find bugs, they are more expensive and provide very slow feedback. Also, depending on the tool you use, they become very brittle and you will end up spending more time maintaining these tests than writing actual production code. The service layer, in the middle, includes integration tests that do not require an UI. In Rails, for instance, you would test your REST interface directly instead of interacting with the DOM elements.
Now, back to your question. I found out that I could greatly reduce the number of bugs in my project, which is a web application written in Spring Roo (Java) with tons of JavaScript, simply by writing enough unit tests for JS. In my application, there is a lot of logic written in JS and that is the kind of thing that I am testing here. I am not concerned about how the page will actually look or if the animations plays as they should. I test if the modules I write in JS will execute the expected logic, if element classes are correctly assigned and if error conditions are well handled. For these tests, I've been using Jasmine. This is a great tool. It is very easy to learn and has nice mocking capabilities, which are called spies. Jasmine-jQuery adds more great functionality if you are using jQuery. In particular, it allows you to specify fixtures, which are snippets of the HTML code, so you don't have to manually mock the DOM. I have integrated this tool with maven and these tests are part of my CI strategy.
You have to be careful with UI tests, specially if you rely on record/playback tools like Selenium. Since the UI changes often, these tests keep breaking and you will spend a lot of time finding out if the tests really failed or if they are just outdated. Also, they don't add as much value as unit tests. Since they need an integrated environment to run, you will mostly like run them only after you finished developing, when the cost of fixing things is higher.
For smoke/regression tests, however, UI tests are very useful. If you need to automate these, then you should watch out for some dangers. Write your tests, don't record them. Recorded tests usually rely on automatically generated xpaths that break for every little change you do on your code. I believe Cucumber is a good framework for writing these tests and you can use it along with WebDriver to automate the browser interaction. Code thinking about tests. In UI tests, you will have to make elements easier to find so you don't have to rely on complex xpaths. Adding class and id elements where you usually wouldn't will be frequent. Don't write tests for every small corner case. These tests are expensive to write and take too long to run. You should focus on the cases that explore most of your functionality. If you write too many tests at this level you will probably test the same functionality that you have previously tested on your unit tests (supposing you have written them).
In my current project I am using Spock and Geb to write the UI tests. I find these tools amazing. They are written in Groovy, which suits better my Java project.
There are lots of options and tools for that. But their choice depends on whether you have a web UI or it's a desktop app?
Supposing from the tools you've mentioned it's Web UI. I would suggest Selenium (aka WebDriver): http://seleniumhq.org/docs/
There is a variety of languages it supports (Ruby is in the list). It can be run against a variety of browsers, ad it's quite easy to use with lots of tutorials and tips available.
Oh, and it's free, of course :)
I though as this post gets a lot of likes, I would post my answer to my question as I do write lots of tests now and how you test front end has moved on a lot now.
So in terms of FE testing I spent lot of time using karma with Jasmine, although karma will work nicely with other test suites like mocha & qunit. While these are great and karma allows you to interface directly with browsers to run your tests. The downside is as your test suite gets large it can become quite slow.
So recently I have moved to Jest which is much faster and if your writing react app, using enzyme with snap shot testing give you really good coverage. Talking of coverage Jest has Istanbul coverage built in and set up and mocking is really easy simple to use. The downside it doesn't test in browser and it using something called jsdom which is fast, but does have a few nuisances. Personally I don't find this a big deal particularly when I compile my code through webpack/babel which means the cross browser bugs are fairly few and far between, so generally isn't an issue if you manually test anyway (and imo you should).
In terms of working within the rails stack, this much easy now that the webpacker gem is now available and using npm and node is generally much more excepted. I would recommend using nvm to manage your node versions
While this isn't strictly testing, I would also recommend using linting as this also picks up a lot of issues in your code. For JS I use eslint with prettier and scss/css I use stylelint
In terms on what to test, I think as Carlos talks about the test pyramid is still relevant, after all the theory doesn't change, just the tools. I would also add to be practical about tests, I would always test, but to what level and coverage will depend on the project. It is important to manage your time and spending hours/days testing a short lifecycle project. Larger/longer term projects the benefits of a larger test suite is obviously greater.
Anyway I hope that helps people that look at the question.