One of the great things about being a web developer in recent history is all the sharing that's going on, especially with JavaScript libraries. There's all these awesome tools to use: jQuery, jQuery-UI, Lightbox, bxslider, underscore.js, Backbone.js, the list goes on. Then there comes a time when one or more of these libraries need to be updated. But JavaScript runs on the client, it doesn't compile, and it's difficult or impossible to be notified when a problem occurs. What is the best technique right now to assure that after you update one or more JavaScript libraries, your web application will not start throwing JavaScript errors?
There's no way the best response to this is to just test. Especially with a complicated application it can be too difficult to go through every possibility and make sure no errors are thrown. What are other web application developers out there doing to make sure they don't have a deployment with an embarassing and crippling JavaScript bug caused by updating?
The best answer is to "just test". What you are asking, essentially, is "How do I test to make sure my software still works?". You can do all the homework you want to see what changed, but eventually you just need to test your application.
That being said, there are generic testing tools like JSLint and Selenium, but ultimately your application is going to be unique enough that you will need to have unit tests to cover the business logic and standard QA for non-standard processes.
One way to ensure that things still work functionally is to have a suite of automated browser tests (utilizing a tool like Selenium) that you run on your development environment.
I wouldn't really call this "just testing" but unit testing will help do the job. Write tests once for your app looking for the expected results (good practice either way), then when you update the plugins run these tests again.
http://qunitjs.com/
Nothing beats a good QA and browser testing though.
Plenty of other answers already include "test", so hopefully that's obvious at this point.
The other thing that you should ALWAYS do is read the release notes for every single version up to the version that you're upgrading to. I can't speak intelligently about bxslider or Lightbox, but the other major libraries that you referenced are extremely good at releasing detailed changelogs which will notify you of breaking changes. You can decide for yourself if any of these changes will have a negative effect on your app ( in addition to testing of course!).
Related
I have been developing phonegap applications that need to make updates oftenly. The problem is pushing a new ipa to iTune Store take too long. So, I uploaded the application source codes(minified javascript) to my server and download it from application and "eval" the minified js files. But i feel using eval has limitations and also not the right way. So, can someone tell me the right way to accomplish this.
thank you so much.
I'd love to have something like this as well. You're already ahead of me w/your eval() approach - but I'd have the same concerns as you there. Here's what I'm aware is out there on this topic - hope this helps?
IdeaPress(?)
I just recently caught wind of this one - not sure how feasible but it claims to do exactly what we'd like. I have to say the main site looks a bit flaky but I will definitly be checking this out to see if it's feasible or not.
HockeyApp?
HockeyApp (possibly dead-end now). I thought there used to be a pretty clear solution for PhoneGap devs to integrate the HockeyApp API/feature set with their mobile apps but a recent Google search on this is turning up much less than I would think - so maybe it's a dead end now? http://goo.gl/GQOv5o
org.apache.cordova.file
This requires more work and I haven't pushed far enough yet to see if it truly could be a means of updating the app post-app-store-deployment. But based on what I've read if you're just updating code for your WebView you shouldn't have to worry about App Store rejection or anything. Related tutorial
Testflight App Testing (Apple)
I haven't gotten to play w/this yet but sounds like it could be promising for at least the beta/testing phase of development. I, like you, need a solution for end-users, not app testers, but I'll still be looking into this soon as it might replace me having to maintain my own over-the-air app installs for the best/testing periods.
Here is the situation: A complex web app is not working, and it is possible to produce undesired behavior consistently. The cause of the problem is not known.
Proposal: Trace the execution paths of all javascript code. Essentially, produce two monstrous logs which can then be fed into a diff algorithm to determine where the behavior related to the bug begins to diverge (as the cause is not apparent from application behavior, and both comprehending and obtaining a copy of the actual JS code being run is difficult, due to the many pages that must be switched to and copied out from the web inspector. Making it difficult is the fact that all pages are dynamically spliced together with Perl code, where significant portions of JS code exist only as (dynamic...) Perl strings).
The Web Inspector in Chrome does not have an option that I know about for logging an execution trace. Basically what I would like is a log of every line of JS that is executed, in the order that they are executed. I don't see this as being a difficult thing to obtain given that the JS VM is single-threaded. The problem is simply that the existing user-facing tools are not designed for quite this much hardcore debugging. If we look at the Profiler in the Dev Tools, it's clearly capable of the kind of instrumentation that I need, but it is fundamentally designed to do profiling instead of tracing.
How can I get started with this? Is there some way I can build Chrome from source, where I can
switch off JIT in V8?
log every single javascript expression evaluated by V8 to a file
I have zero experience with the development side of Chrome. So e.g. links to dev-builds/branches/versions/distros of Chrome/Chromium/Canary (what's the difference?) are welcome.
At this point it appears that instrumenting the browser with powerful js tracing is still likely to be easier than redesigning the buggy app. The architecture of the page is a disaster, but the functionality is complex, and it almost fully works. I just have to find the one missing piece.
Alternatively, if tools of this sort already exist, what are some other keywords I can search for them with? "Code Tracing" is pretty much the only thing I can come up with.
I tested dynaTrace, which was a happy coincidence as our app supports IE (indeed Chrome support just came out of beta), but this does not produce a text dump, it basically produces a massive Win32 UI expando-tree, which is impossible to diff. This makes me really sad because I know how much more difficult it was to make the representation of the trace show up that way, and yet it turns out being almost utterly useless. Who's going to scroll up and down that tree view and see anything really useful in it, in anything other than a toy example of a web app?
If you are developing a big web app, it is always good to follow a test driven strategy for the coding part of it. Using just a few tips allows you to make a simple unit testing script (using QUnit) to test pretty much all aspects of your app. Here are some potential errors and some ways of solving them.
Make yourself handlers to register long living Objects and a handler to close them the safe way. If the safe way does not succeed then it is the management of the Object itself failing. One example would be Backbone zombie views. Either the view has bad code in the close section, the parent close is not hooked or an infinite loop happened. Testing all view events is also good, although tedious.
By putting all the code for data fetching inside a certain module (I often use a bunch of Backbone.Model objects for each table/document in my DB) and handlers for each using a reqres pattern, you can test them 1 by 1 to see if they all fetch and save correctly.
If complex computation is needed, abstract it in a function or module so that it can be easily tested with known data.
If your app uses data binding, a good policy is to have a JSON schema for all data to be tested against your views containing your bindings. Check against the schema all the data required. This is applied to your Backbone.Model also.
Using a good IDE also helps. PyCharm (if you use Python for backend) or WebStorm are extremely good for testing and developing JavaScript/CoffeeScript. You can breakpoint and study your code at specific locations, inside your browser! Also it runs your code for auto-completion and you can see some of the errors that way.
I just cannot encourage enough the use of modules in your code. Although there is no JavaScript official way of doing it (next ECMAScript draft has it), you can still use good libraries for it. Good ones are: RequireJS, CommonJS or Marionette.Module (if you use Marionette as your framework). I think Ember/AngularJS also offers this kind of functionality but I did not work with them personally so I am not sure.
This might not give you an immediate solution to your problem and I don't think (IMO) there is an easy one either. My focus was to show you ways to develop so that errors can be easily spotted and countered, and all of it (depending on your Unit Testing) during development phase. Errors will always happen, as much as our programmer ego wants us to believe the contrary. Hope I helped :)
I would suggest a divide and conquer strategy, first via logging, and second via code. Wrap suspect methods of the code with console logging in and out events and when the bug occurs hopefully it is occurring between or after some event. If event logging will not shed light, bring parts of the code into a new page/app. Divide and conquer will find when the error starts occurring.
So it seems you're in the realm of weird already, so I'm thinking of a weird solution. I know nothing about the backend of chrome myself so we're in the same boat, but if you're feeling bold here's an idea. Maybe you could find/replace every newline in your javascript files with a piece of code that logs either to a global string or to the console a) what file you're in, b) the contents of "this" or something useful to you, and maybe even c) the time. This would at least get you started. Make sure it's wrapped in something distinct so you can just as easily remove it.
The application that I'm currently working on is a simple 3-tier web application (whatever simple means :) However, the application is very UX/UI intensive i.e. the user-interface forms the crux of application. Every structural change to the page or refactoring javascript/jquery/backbone code, we need to ensure that the UI is behaving as expected.
For example, if div's are disappearing on deleting the object, or if items are being successful 'posted' and displayed in a different div etc.
I'm relatively new to the domain of UX/UI-based testing and not sure how to attack this problem. As of now it's quite a manual overhead to ensure it looks and works right. We do have 'one layer below' tests where we send HTTP messages and all seems to work fine with the return codes etc. But UI focused testing is what we lack.
I've heard about Selenium, Jasmine and a few Javascript frameworks but am not sure if they serve my needs. As of now the solution I see is to custom code javascript tests that would 'autorun' these tests from a browser and check if things are happening the way they should (probably with a human just 'staring' at the screen :) This itself will be quite a task and I thought of asking the community on suggestions before we reinvent the wheel.
Question: What tools/techniques are best suited for this type of a
job?
PS: It's a Java/Restlet based web-application
Selenium can definitely do what you need if you're looking to build 'real' automation tests, meaning code-based testing in something like Java, .NET or any of the other supported 'server-side' languages.
This would be far more likely to help detect regression than javascript-based tests where you have sometimes have limited ability to properly replicate user-interactions if it wasn't designed to allow it. Some things you would find are nearly impossible to test with just javascript.
Its worth the effort and Selenium is supported very well across many languages. Its essentially the industry standard and you'll find lots of documentation and helpful frameworks to get you started.
I'm about to write a simple HTML5 + JavaScript (jQuery) app in my spare time in order to keep up with the latest web technologies (at work it's more advanced C# backend stuff).
I'd like to develop in the same fashion that I've done for the last ten years or so, namely TDD style.
Being new to the TDD/BDD/AcceptanceTDD world in HTML/JavaScript, my question is: is there a great framework or the like for writing test against a web page in a browser (out-of-the-box support for many browsers being a definitive plus)?
The reason I'd like to use JavaScript is two-fold. 1. I'd like to learn more JavaScript, and 2. I'd like to use the same language(s) for the tests as I do for development.
Otherwise, I could simply use my C# skills and use Selenium, WatiN, or a similar framework.
I've found Jasmine, QUnit, and a homegrown solution using jQuery at MSDN, but don't get a feel for the flow nor complexity, so recommendations and first hand experiences are more than welcome.
JS Test Driver is the framework recommended by the Javascript TDD book from O'Reilly that I'm reading right now. I haven't actually had a chance to play with it much yet, but:
A dude who wrote a book on JS testing recommends it
It has a very nice feature set (automated test running across multiple browsers being key)
It comes from Google (love 'em or hate 'em, they have a lot of smart JS people working there)
So at the very least it's worth checking out I think.
At this point, I'd recommend Jasmine. I've used it successfully on a few projects. I haven't really run up against too many frustrating situations where I just couldn't get something done (unlike other tools). It can be set up in different configurations, depending on your preference-- it can be as simple as opening a page in a browser, or it can be "served" dynamically.
There are dozens of tools out there in general usage-- and so far-- no clear winner. I've tried a quite a few of them, and-- as John Resig points out-- creating a simple testing framework isn't that complicated. But adding some tools to make it convenient is important. Jasmine is the most complete one I've used, but it's not bloated.
Important considerations:
set up: don't adopt a tool that doesn't work easily out of the box
style: use a tool that makes sense to you in the context of the rest of your testing tools. For example, if you use BDD tools, find a BDD Javascript framework. This is probably the biggest variance in the frameworks-- might as well pick one that has a syntax you like.
cross-browser: the tests should work across browsers
automation: you should be able to script the running of the tests in one or multiple browsers
testing time-based code-- if you Javascript has behavior tied to the clock (as in animations), having a testing framework the facilitates this is nice
mocking: jasmine has a nice mocking support that really helps
You really do not need to use Selenium for simple unit tests-- it complicates the configuration and is a more difficult programming model than a simple unit testing framework.
I've struggled with this a lot. I think Selenium is your best bet especially since it sounds like you've used it before. The other stuff for JS is mostly unit testing.
Not to diminish machineghost's answer, JS Test Driver rocks for unit testing.
I ended up using QUnit since I found it very simple to just insert the PUT (Page Under Test) in an <iframe>, and use jQuery to access it from the unit tests.
That way I don't need any other external dependencies other than the browser itself (the logic resides 100% in the client) and any text editor.
Turboframework uses javascript, jasmine, selenium and runs with node. You can literally create a test project and run web automated tests in less than 10 minutes. To avoid repeating the documentation that is already available, here's the link to a quick start guide:
https://turboframework.org/en/blog/2021-03-03/automate-your-web-application-tests-in-less-than-ten-minutes
Is JSunit really a direct port of Junit to Javascript? So I have heard, but I am wondering why my company is not using it. My company has lots of smart minds, so If we are not using it I wonder if there are any major issues with Jsunit as a javascript test harness.
Input would be much appreciated.
thanks!
JsUnit is an adaptation of JUnit for Javascript, not a direct port. It's very nice, but is showing its age and is no longer actively developed.
Check out Jasmine -- for a modern and actively supported alternative, written by the same people who wrote JsUnit.
You mean this jsunit?
Maybe the smart guy's at your company do not even know it exists (actually, learning such things is one of the reasons I read SO). Maybe they haven't yet had the time to evaluate this for real use and deployment, or play with something else.
The tool is not the only thing that is needed to deploy a testing discipline: you need automated test replay, reporting to track deviations and progress, test methodologies, best practices.
You also need documented objectives, and proper training for the teams. that is why in general companies with smart guys do not change tools every time a new tool is around, and sometime do not deploy all best practices immediately.
But in general this does not prevent individuals to deploy them for themselves, try tools, and even succeed to make the whole company evolve and use better processes, eventually building (even) better products.