Are there any unit testing solutions for Flex? or actionscript 3?
If so, what are their features? Any UI testing abilities? Functional testing? Any pointers, examples, libraries or tools that you can share?
FlexUnit is pretty awesome - http://opensource.adobe.com/wiki/display/flexunit/FlexUnit
Also ASUnit - http://asunit.org
They are both pretty similiar and both haven taken quite a bit from frameworks like JUnit.
FlexMonkey (http://code.google.com/p/flexmonkey/) although I haven't used it myself seems to do UI unit testing.
I just found fluint, and it was a great unit testing library, better than both Flexunit and ASUnit imho. It handles asynchronous testing really nice.
I can confirm that FlexMonkey indeed does UI unit testing. It provides record/playback of UI interactions and generates FlexUnit test cases.
Check it out at http://flexmonkey.googlecode.com
I would recommend FlexUnit, too... and you also have a look at Visual FlexUnit.
A few days before I found the RIATest-Tool, but I haven't tried it yet.
I'd recommend fluint simply due to it having a more active developer base (and it's improved support of testing asynchronous code). Also, if you are after mocking/stubs there is asmock (a dynamic mocking framework) and mock-as3 (a static mocking framework).
For asynchronous unit testing dpUint is pretty useful. However FlexUnit is the way to go, if you wish to integrate unit testing with a Maven build. Asynchronous testing (e.g. Cairngorm events) can also be done with FlexUnit, but is not as elegant as with dpUint.
Try mockito for flex http://bitbucket.org/loomis/mockito-flex
Related
I read that Mockito 2 doesn't use CGLIB/proxy any more but instead uses ByteBuddy for mock creation. Does that mean that from now on it is possible to mock static methods and private methods?
No, you can't (see their documentation here; I am sure they would mention that).
So, PowerMock(ito) and JMockit are the two mocking frameworks that support mocking static methods.
But, some personal opinion: one should nonetheless prefer to use Mockito instead PowerMock(ito); simply by writing code that can be tested with Mockito; and that doesn't need PowerMock. What I mean is: when you write your own code and you think you need to mock static calls; then you are writing hard to test code.
The answer is not to look to powerful mocking frameworks; but to write easy to test code instead. You can have a look into these videos to learn how to do that.
Finally: don't think that PowerMockito is a good alternative. Mockito is right now at version 2.79 (as of March 2017). But when you have a look at PowerMockito; you will find that it ships with some Mockito 2.0.42 beta something - because the PowerMockito folks can't get their tool working with any newer version of Mockito. And that is a shame, because those newer Mockito versions have a lot of interesting features.
I wrote an extension of Mockito 2 which uses AspectJ to allow mocking even things like static/private/final methods, with one easy lambda-based syntax, for example:
when(() -> YourClass.staticMethodToCall(...)).thenReturn(...)
I'd like to define two different suites in the same JUnit TestCase Class; one for behaviour tests and another for efficiency tests. Is it possible?
If yes, how? If not, why not?
Additional details: I'm using JUnit 3.8.1.
If I understand you correctly, you're trying to partition your tests. Suites, on their own, are not really the mechanism you need, rather it's JUnit's categories you need to investigate:
http://java.dzone.com/articles/closer-look-junit-categories
I've not used these as I've usually found the overhead of test partitioning too much effort, but this may work for you. I think TestNG has supported this concept for quite a while.
Also, if you're using Maven you get a partitioning of tests into unit and integration tests for free - check out the Failsafe plugin - which is good for separating tests you want to run quickly as part of every build from longer running tests.
I'm a bit new to actionscript, but find myself investigating good programming practices from other OO languages (java/C#) into an actionscript environment. I've given Mock4as and mockito-flex a purusal and was interested in using both.
Has anyone had good/bad experiences using either?
I started out mocking for FlexUnit with mock4as, and it does its job. But it made me spend way too much time writing boilerplate code for my taste. I haven't tried mockito-flex, but I'll check it out - the Java version I really like.
Recently, I've been really happy with mockolate. Drew Bourne does a really nice job with that - give it a try!
I have had excellent experience with Mockito-flex for the past couple years. The primary reason I enjoy Mockito-flex over Mocholate is that Mockito lets you test your code using the actual class signatures, thus refactor tools will update your Tests.
Mocholate on the other hand requires that you hardcode the method names with a string, which means no auto-complete help when your creating your tests, and poorer refactoring support if any if you rename and API.
While less important, Mockito is available for multiple languages. This means that you can use the same mocking syntax in your entire tech stack. Or you can more easily transfer you mocking skills to another language.
Having recently read "Growing OO systems guided by tests", I am very impressed with the windowlicker testing utility for java/junit. Basically it wraps the GUI and GUI-interaction with drivers and gestures, so your integration/end-to-end tests can be written neatly like:
//setup
ui.enterUserDetailsFor(newUser)
ui.sendForm()
//assert
ui.showsWelcomeMessage()
All swing-gui-thread synchronization and finding widgets etc is nicely isolated in the framework. Exactly this sort of higher level testing is something I really miss in my current wxPython project. Is there anything at all similar for wxgtk/wxpython?
What I can tell from the windowlicker source it builds on java.awt.robot, if there isn't a windowlicker, is there anything like robot?
I haven't heard of anything specifically for wxPython. You can use the Widget Inspection Tool for some of the stuff you are talking about though. See here:
http://wiki.wxpython.org/Widget%20Inspection%20Tool
There's also the Sikuli project which is GUI-agnostic:
http://groups.csail.mit.edu/uid/sikuli/
Hopefully one of those will help you out.
There is so much written about unit testing but I have hardly found any books/blogs about integration testing? Could you please suggest me something to read on this topic?
What tests to write when doing integration testing?
what makes a good integration test?
etc etc
Thanks
Anything written by Kent Beck, father of both JUnit and SUnit, is a great place to start (for unit tests / test writing in general). I'm assuming that you don't mean "continuous integration," which is a process-based build approach (very cool, when you get it working).
In my own experience, integration tests look very similar to regular unit tests, simply at a higher level. More mock objects. More state initialization.
I believe that integration tests are like onions. They have layers.
Some people prefer to "integrate" all of their components and test the "whole" product as an the "integration" test. You can certainly do this, but I prefer a more incremental approach. If you start low-level and then keep testing at higher composition layers, then you will achieve integration testing.
Maybe it is generally harder to find information on integration testing because it is much more specific to the actual application and its business use. Nevertheless, here's my take on it.
What applies to unit-tests also applies to integration tests: modules should have an easy way to mock their externals inputs (files, DB, time...), so that they can be tested together with the other unit-tests.
But what I've found extremely useful, at least for data-oriented applications, is to be able to create a "console" version of the application that takes input files that fully determine its state (no dependencies on databases, network resources...), and outputs the result as another file. One can then maintain pairs of inputs / expected results files, and test for regressions as part of nightly builds, for example. Having this console version allows for easier scripting, and makes debugging incredibly easier as one can rely on a very stable environment, where it is easy to reproduce bugs and to run the debugger.
J.B. Rainsberger has written about them. Here's a link to an InfoQ article with more info.
http://www.infoq.com/news/2009/04/jbrains-integration-test-scam