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.
Related
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!).
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.
For a quite long time I was used to use the Flash Builder (previously called "Flex") enviroment to build complex applications, and in my current project (cant say what project is, sory) Im part of a RIA made in Flex, using mxml, AS3, some JS, etc.
The performance is below average.
The site feels like u need a powerful PC to run it something close to smooth.
And Im working with very talented ppl here, or at least thats what I can perceive.
So my question is, there is a posibility that the next version of the website will be made in pure HTML + CSS + JS, to obtain a more responsive feeling when u use the site, is something at least close to what FB can do for you in terms of a project-oriented enviroment?
On another hand, this general laggy and low performance thing is a programmer related issue, or it cant be avoided since "its just Flash" ?
Thanks!
(Im a big fan of flash tbh, but I try to keep my mind open in this)
Everything depends on what you're trying to do and if your programmers know how do to their jobs. If they don't take care, then it's very easy to create an application in Flash, and especially Flex (as you really need to know the internals of Flex to understand what it will do and when), that saps memory and power so that you need a beast of a machine to run it. Optimisation is a large topic, but fortunately, the web is covered in links on what not to do, or tips on how to use Flash to it's full potential.
As a quick test, open up the task manager, then run your app (close down all other programs using flash, including gmail, web radio etc), then watch the memory usage. If it's continually climbing, then there's a problem in your code.
Alternatively, if you have a bit more time, build some debug tools into your app so you can see what's going on in terms of framerate and memory usage - try the FlashPreloadProfiler for a quick fix: http://jpauclair.net/flashpreloadprofiler/
If your app shouldn't be complex but it's lagging (by complex, I don't mean the actual purpose of the app, but rather what it's showing on the screen, effects etc), then the problem is that there's misuse somewhere.
Go the HTML5 route if you feel it's the best solution for your site/app, but you'll probably encounter the same problems. In some situations, it's slower, in others Flash wins by a country mile. Again, it comes down to the devs
We built Dedoose in Flash Buidler 4, check it out... the performance is freaking great, and it's is a GIANT web app that handles an enormous amount of data. Flash Player in general does have performance problems, but with great engineering and knowledge of how to squeeze good performance out of it, I personally do not see a better alternative, excerpt for maybe silverlight if your requirements fit. For guidance on performance improvements a good place to start is all of Grant Skinner's articles over at http://gskinner.com/blog
Additionally, I can't really see what the actual question your asking is, what are the alternatives? HTML5+CSS is good, but good luck getting any good productivity out of your team developing a large scale web app in it. Silverlight is pretty dang good if you can force plugins down the users throat, Java is suffers the same dilemna. Personally I would read up more on getting good performance out of flash, then learn exactly how the flex framework works in terms of what it builts upon flash with, then... if u want real performance, ditch most of the flex framework and use things like MinimalComps and custom built components. Have you used the Flex Builder Profiler to analyze where your slow downs are occuring?
~ JT
If it's just an IDE you want, I'll give a nod to Flash Develop: http://www.flashdevelop.org/wikidocs/index.php?title=Main_Page
Not all the power of Flash (Flex) Builder, and without the design view. But it's free, open source, and community driven. I personally prefer the style of context highlighting and code completion hints in Flash Develop.
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
We currently have a quite complex business application that contains a huge lot of JavaScript code for making the user interface & interaction feel as close to working with a traditional desktop application as possible (since that's what our users want). Over the years, this Javascript code has grown and grown, making it hard to manage & maintain and making it ever more likely that adding new functionallity will break some existing one. Needless to say, lots of this code also isn't state of the art anymore.
Thus, we have some ongoing discussion whether the client-side part of the application should be written anew in either Flex or Silverlight, or written anew with some state of the art JavaScript framework like jQuery, or whether we should simply carry on with what we have and gradually try to replace the worst bits of the existing code. What makes this even harder to decide is that writing the UI anew will probable cost us 6-12 person months.
I'd like to hear your thoughts on that issue (maybe some of you have already had to make a similar decission).
EDIT: To answer some of the questions that came up with the answers: The back-end code is written in C#, the target audience are (usually) non-technical users from the companies we sell the software to (not the general public, but not strictly internal users either), the software 'only' has to run in desktop browsers but not necessarily on mobile devices, and the client app is a full-blown UI.
In all honesty, I would refactor the old JavaScript code and not rewrite the application. Since you are asking about which platform to put it in, I would guess that your team isn't an expert in any of them (not slamming the team, it's just a simple fact that you have to consider when making a decision). This will work against you as you'll have double duty rewriting and learning how to do things on the new platform.
By keeping it in JavaScript, you can slowly introduce a framework if you choose and do it iteratively (Replace on section of code, test it, release it, and fix any bugs). This will allow you to do it at a slower pace and get feedback along the way. That way too, if the project is canceled part way through, you aren't out all the work, because the updated code is being used by the end users. Remember the waterfall model, which is essentially what a full swap out of will be almost never works.
As much as I hate to admit this, as it is always the most fun for developers, shifting platforms, and replacing an entire system at once rarely works. There are countless examples of this, Netscape for one. Here is the post from Spolsky on it. (I would also recommend the book Dreaming in Code. It is an excellent example of a software project that failed and how and why). Remember to rewrite a system from scratch you are essentially going to have to go through every line of code and figure what it does and why. At first you think you can skip it, but eventually it comes down to this. Like you said, your code is old, and that means there are most likely hacks in it to get something done. Some of these you can ignore, and others will be, "I didn't know the system needed it to do that."
These things spring to mind:
As you have a .Net backend and you have some ability to force your customers onto a specific platform, Silverlight is an option;
Since your client is a full-blown UI you want widgets and possibly other features like Drag and Drop;
I haven't seen any requirements that to me would justify starting over (which often doesn't work out) in Flex/Silverlight (eg streaming video, SVG support. Added to your team's familiarity with Javascript, I think you can't make a compelling case for doing it in anything other than Javascript.
But of course Javascript is lots of things and there are [lots of Javascript frameworks1. The most important divider is whether your intent is to "decorate" a set of Web pages or you need a full set of Widgets to create a desktop-like application on the Web. Your question indicate it is the latter.
As such--and I may get downvoted for saying this--I don't think jQuery is the answer and I say this as someone who loves jQuery. jQuery (imho) is great to enhance Webpages and abstract cross-browser low-level functionality but the most important factor for complex UI developer is this:
It's all about the widgets.
And yes I'm aware of jQuery UI but it's a lot sparser than the others when it comes to widgets. I suggest you take a look at the samples and widget galleries of some frameworks:
YUI Examples Gallery;
ExtJS demo; and
SmartClient feature explorer.
The others (jQuery, Dojo, Mootools, Prototype) are more "compact" frameworks arguably less suited to your purpose.
Also consider the license of each framework when making your decision.
My thoughts on the above three are:
ExtJS has somewhat angered the community in that it started out as LGPL but had a controversial license change (that thread is at 76 pages!) to GPL/commercial at version 2.1. The problem with that the community no longer has an active participation in the framework's development. Not the mainline version anyway. This means it's being developed and supported by a small team (possibly one person) rather than the community. IMHO it's not worth paying a commercial license for that and GPL is probably prohibitive in your situation;
YUI is supported by Yahoo and available under a far more permissive and far less invasive BSD license. It's mature, well-used and well worth serious consideration; and
SmartClient impresses me a lot. It has perhaps the most permissive license of all (LGPL), is roughly seven years old, has an incredibly impressive array of widgets available. Check out their feature explorer.
Your decision should be based on how you get as much of your application "for free" as possible. You don't want to spending valuable developer time doing things like:
Coding UI widgets like trees and accordions;
Testing and fixing cross-browser Javascript and CSS issues;
Creating homegrown frameworks that greatly duplicate what existing frameworks do and do well.
I would seriously look at one of the above three as your path forward.
This decision is usually less about the technology, and more about your skill sets and comfort zones.
If you have guys that eat and breathe Javascript, but know nothing about .net or Flash/Flex then there's nothing wrong with sticking with Javascript and leaning on a library like jQuery or Prototype.
If you have skills in either of the others then you might get a quicker result using Silverlight or Flex, as you get quite a lot of functionality "for free" with both of them.
My opinion on this one's pretty simple: unless the app needs to be accessible publicly, unless it needs to be search-engine optimized and findable, and/or there's an otherwise compelling case for its having to remain strictly text-based, then the chips are stacked in favor of rich-client runtimes like Flash or Silverlight right out of the gate.
A big reason, if not the biggest, is that they eliminate the complexities of developing for multiple browsers and platforms. Again: they eliminate the runtime-environment variable. No more debugging old versions of Netscape and IE, no more object detection and consequent branching, no more wacky CSS hacks -- one codebase, and you're done. Offloading the runtime environment to Adobe or Microsoft will save you time, money and headaches, all else equal. (Sure, there's YUI, JQuery, etc., but they don't eliminate that variable -- they just abstract it. And they don't abstract all of it, either -- only some of it; ultimately, it's still up to you to test, debug, retest, debug, repeat.)
Of course, your situation's a bit more complicated by the existing-codebase problem, and it's difficult to say definitively which way you should go, because only you've got the code, and we're just geeks with opinions. But assuming, just by your asking the question, that a refactoring of your existing codebase would involve a significant-enough undertaking as to warrant even considering an alternative (and probably comparatively foreign) technology in the first place, which it sounds like it would, then my response is that your curiosity is well-placed, and that you should give them both a serious look before making a decision.
For my part, I'm a longtime server-side guy, ASP.NET/C# for the past several years, and I've written many a text-based line-of-business app in my time, the last few with strong emphasis on delivering rich soverign UIs with JavaScript. I've also spent the last couple of years almost exclusively with Flex. I've got experience in both worlds. And I can tell you without hesitation that right now, it's everyone else's job to beat Flex: it's just an amazingly versatile and productive product, and for line-of-business apps, it remains leaps and bounds ahead of Silverlight. I just can't recommend it highly enough; the data-binding and event-handling features alone are incredible time-savers, to say nothing of the complete freedom you'll have over layout, animation, etc. The list goes on.
So, my advice: take a long, careful look at Flex. In the end, you might find a ground-up rewrite is just too massive an undertaking to justify, and that's fine -- only you can make that determination. (And to be fair, you've just as much ability to make a mess of a Flex project as you do with a JavaScript project -- I know. I've done it.) But all told, Flex is probably the least-limiting, most flexible, most feature-rich and productive option out there right now, so it's certainly worth considering. Good luck!
Any javascript you have that has been developed 'Over the years' probably doesn't look anything like what's possible today. You undoubtedly have a lot of useful code there. nonetheless. So my recommendation would be re-write in javascript using jQuery and make use of one of the available GUI add-ons, perhaps look at Yahoos stuff. You will also be targeting the widest audience this way.
The GUI technology should be first and foremost determined by your target audience. For instance, if you target englobes iPhone users, I would not recommend Flex, because iPhone doesn't have a flash player at the moment.
Bear in mind that if you switch to a full fledged GUI toolkit like Silverlight, your users may find the L&F unnatural, since the usual request-reply cycle is not so evident with client-side frameworks.
After that, it is your developers that should have a word to say. Every toolkit needs maintenance, and if you are switching to a whole new toolkit the developers will have to familiarize with the new toolkit, which can be costly.
My suggestion is that you stick to javascript, since your devs are familiar with it, and gradually replace the old javascript with a new toolkit like prototype, jQuery or any other. You will probably redo some of the old stuff faster using a state-of-the-art toolkit. Remember that you can build beautiful apps with any tookit.
We have developed an extremely rich application using EXTJS with C# and a some C++ on the server. Not only do we have clients who are happy with the interface in their desktop browsers but with very little tweaking to the Javascript we were able to provide web browser support. Also, we have clients in third-world countries who cannot use Flash or Silverlight apps due to their field personnel using kiosks in internet cafes (many of which don't have Flash installed - forget Silverlight!). I think these issues and others make up for the difficulty of coding a complex app in javascript...
Check this comparison table for Flex vs Javascript: