I am coding a client-server application using Eclipse's RCP.
We are having trouble testing the interaction between the two sides
as they both contain a lot of GUI and provide no command-line or other
remote API.
Got any ideas?
I have about 1.5 years worth of experience with the RCP framework, I really liked it. We simply JUnit for testing...
It's sort of cliche to say, but if it's not easy to test, maybe the design needs some refactoring?
Java and the RCP framework provide great facilities for keeping GUI code and logic code separate. We used the MVC pattern with the observer, observable constructs that are available in Java...
If you don't know about observer / observable construct that are in Java, I would HIGHLY recommend you take a look at this: http://www.javaworld.com/javaworld/jw-10-1996/jw-10-howto.html, you will use it all the time and your apps will be easier to test.
As a former Test & Commissioning manager, I would strongly argue for a test API. It does not remove the need for User Interface testing, but you will be able to add automated tests and non regression tests.
If it's absolutely impossible, I would setup a test proxy, where you will be able to:
Do nothing (transparent proxy). Your app should behave normally.
Spy / Log data traffic. Add a filter mechanism so you don't grab everything
Block specific messages. Your filter system is very useful here
Corrupt specific messages (this is more difficult)
If you need some sort of network testing:
Limit general throughput (some libraries do this)
Delay messages (same remark)
Change packet order (quite difficult)
Have you considered using a UI functional testing tool? You could check out HP's QuickTest Professional which covers a wide varieties of UI technologies.
we are developing one client-server based application using EJB(J2EE) technology, Eclips and MySQL(Database). pl suggest any open source testing tool for functional testing .
thanks
Hitesh Shah
Separate your client-server communication into a pure logic module (or package). Test this separately - either have a test server, or use mock objects.
Then, have your UI actions invoke the communications layer. Also, have a look at the command design pattern, using it may help you.
Related
I have recently come across the Citrus framework and was trying to use it.
But I found I can use Mockito as well in mocking the external service to do some Integration testing of my code.
What are specific advantages of using Citrus over Mockito?
I have recently come across the Lasagne and was trying to eat it. But I found I can use Pizza as well in eating at the dinner to do some food filling of my stomach.
What are the specific advantages of eating Lasagne over Pizza?
Do you get my point here? Your question is way too generic to get a good answer as you always need to decide based on the use case and what you want to do. Besides that Mockito and Citrus are not really competitors in my opinion as they have completely different focus.
Mockito and Citrus both are test frameworks, right but they have completely different goals in testing your software.
Mockito is used in unit testing with a more deep insight of classes and methods used so you can create a level of abstraction when testing a piece of your code. Citrus has focus on integration testing with messaging interfaces involved where your application under test is deployed somewhere in a shippable state and messages do really go over the wire.
At the moment you are doing unit testing not integration testing. Which is great! You need a lot of unit tests and Mockito is a really good choice to help you there. At some point you may want to test your software with focus on integration with other components in a production-like environment with completely different focus (non-functional requirements, deplyoment, configuration, messaging, security and so on). This is the time to go for integration testing to make sure that you meet the interfaces to other components and to make sure that others can call your services in a well designed way.
Which part of the testing train you need and which part you may want to stress in your project is totally based on the requirements and your software architecture.
Long sentence short I would recommend that you go three steps backwards in order to clarify what you want/need to test in your application and then pick the tools that help you to reach that goals.
I'm developing a gateway that will be located between mobile web apps and web services on backend systems. The purpose of this gateway is to protect web apps against changes to backend web service api's, to introduce concurrency, transform messages, buffering, etc.
My proposed architecture is as follows:
Platform independent mobile web apps using PhoneGap (done)
Gateway is a web service using Scala for business logic and ZeroMQ for message passing (new)
Backends are existing web services (existing)
The gateway is purely responsible passing, translation, aggregation, etc. of messages and does not need to keep state or do user authentication at this point - it's simply responsible for being a single interface that knows how to talk to mobile apps on the one side and one or more services on the other side.
I'm strongly considering using Scala as the development language because it seems well suited for this type of application, but what would be the correct architecture for such a Scala service? I looked at frameworks such as Lift and Play and also considered doing a simple "java" based web service and just use Scala as to implement my business logic. I believe strongly in keeping things as simple as possible. I'm wary of complicated setups and thousands of lines of dead code in frameworks that may never be used. On the other side, limiting oneself to a 'role your own' solution and creating a lot of work and having to maintain code that may have been part of existing solutions is also not ideal.
Some things to consider: I'm the architect and developer, but my knowledge of Scala is limited to the first half of "Programming in Scala, Second Edition". Also, my time is very limited. Still, I want to get this right the first time.
I'm hoping that some clever gent or dame will provide me with insights to this type of solution and maybe a link or two to get started quick. I really need to get going FAST, but hope that the experience or insights of another professional could help me avoid pitfalls along the way. Any insights to development environments and tools will also be helpful. I have to develop on Mac (company rules) but will be deploying on Ubuntu server. I'm currently juggling between installs of Eclipse or Idea as IDE's and the scala compiler or sbt for building.
UPDATE
Thanks for all the potential answers below. I had a look at each and every suggestion and all of them have merit. The problem is now to bet on the right horse. Spray is possibly the simplest solution to the problem, but I also found Finagle. It seams like a stunning solution to my problem. I'm a bit concerned that it is built on top of Netty instead of Akka. Does anyone see any problem with that. I was hoping to keep my solution as purely Scala as possible, but Finagle appears to be the most mature of the lot. Any ideas?
It might be worth taking a look at Akka, which provides a lightweight framework for writing concurrent, fault-tolerant applications on the JVM, as well as useful built-in abstractions for writing web services. In addition, the Spray project looks like it could be useful for your purposes, providing HTTP server and client libraries on top of Akka (Although, unlike Akka itself, I haven't used this so myself so can't vouch for it).
If you're using a web service that is purely for other services, then an Akka based service like Spray or Blueeyes is probably your best bet. You can use Jerkson to do the JSON mapping to and from your case classes and use Akka-Camel to link to ZeroMQ.
As mistertim says, Akka is a good option. I'm biased, but I think Lift and its RestHelper is a fantastic way to go also (I've built several APIs for iPhone apps using Lift). Beyond those, I know several people who are very happy with Unfiltered.
Unfiltered is very interesting option if you want to keep it lightweight, as is not a full blown web framework.
To be honest, the documentation can use more detail, but to provide a web service you just write:
object MyService extends unfiltered.filter.Plan {
def intent = {
case req # GET(Path ("/myendpoint")& Params(params)) =>
for {
param1<-params("param1")
param2<-params("param2")
} yield ResponseString(yourMethod(param1,param2))
}
override def main(args:Array[String]) = unfiltered.jetty.Http.anylocal.filter(MyService).run();
}
Very useful if you don't want to use a framework and don't want to mix java/java annotations with Scala (otherwise, you have the usual java solutions)
Still, I would recommend to look into Akka if you think you think actors will fit your problem
If your system is middle-ware and get the things done quickly, then Spray will be a best. Spray was developed on top of Akka. Akka has ZeroMQ support.
in future if you are going to add some other web like module along with your middle-ware, then choosing Lift + Akka will be better because, Lift also provides Spray like web service stuff + it will be easy to start developing other modules.
You can choose SBT as your build, there are some project templates, template generation tools available, so you can get the project build very quickly.
In my experience , SBT + InteliJ Idea works well, have a look on sbt-idea plugin
Spray Project Template
Lift Project Template Generator
I am about to start building an app that will be used across all platforms. I will using monotouch and monodriod so I can keep things in .net
I'm a little lazy so I want to be able to reuse as much code as possible.
Lets say I want to create an application that stores contact information. e.g. Name & Phone number
My application needs to be able to retrieve data from a web service and also store data locally.
The MVVM pattern looks like the way to go but im not sure my approach below is 100% correct
Is this correct?
A project that contains my models
A project that contains my views,local storage methods and also view models which I bind my views to. In this case there would be 3 different projects based on the 3 os's
A data access layer project that is used for binding to services and local data storage
Any suggestions would be great.
Thanks for your time
Not specifically answering your question, but here are some lazy pointers...
you can definitely reuse a lot of code across all 3 platforms (plus MonoWebOS?!)
reusing the code is pretty easy, but you'll need to maintain separate project files for every library on each platform (this can be a chore)
MVVM certainly works for WP7. It's not quite as well catered for in MonoTouch and MonoDroid
some of the main areas you'll need to code separately for each device are:
UI abstractions - each platform has their own idea of "tabs", "lists", "toasts", etc
network operations - the System.Net capabilities are slightly different on each
file IO
multitasking capabilities
device interaction (e.g. location, making calls etc)
interface abstraction and IoC (Ninject?) could help with all of these
The same unit tests should be able to run all 3 platforms?
Update - I can't believe I just stumbled across my own answer... :) In addition to this answer, you might want to look at MonoCross and MvvmCross - and no doubt plenty of other hybrid platforms on the way:
https://github.com/slodge/MvvmCross
http://monocross.net (MVC Rather then Mvvm)
Jonas Follesoe's cross platform development talk: Has to be the most comprehensive resource out there at the moment. He talks about how best to share code and resources, abstract out much of the UI and UX differences, shows viable reusable usage of MVVM across platforms and nice techniques for putting together an almost automated build. (yes, that includes a way for you to compile you monotouch stuff on Visual Studio)
Best of all he has a available source code for the finished product and for a number of the major component individually placed in its own workshop project and a 50 + page pdf detailing the steps to do so.FlightsNorway on github
IMO the only thing missing is how best to handle local data storage across all platforms. In which case I would direct you to Vici Cool Storage an ORM that can work with WP7, MonoTouch and (while not officially supported) MonoDroid.
*Disclaimer* The site documentation isn't the most updated but the source code is available. (Because documentation is Kriptonite to many a programmer)
I think the easiest way to write the code once and have it work on all three platforms will probably be a web-based application. Check out Untappd for example.
You can start by looking at Robert Kozak's MonoTouch MVVM framework. It's just a start though.
MonoTouch MVVM
Anyone who develops knows that code is a living thing, so how do you go about defining a "complete" interface when considerable functionality may not have been recognised before the interface is published?
Test it a lot. I've never encountered a panacea for this particular problem - there are different strategies depending on the particular needs of the consumers and the goals of the project - for example, are you Microsoft shipping the ASP.NET MVC framework, or are you building an internal LoB application? But distilled to its simplest, you can never go wrong by testing.
By testing, I mean using the interface to implement functionality. You are testing the contract to see if it can fulfill the needs. Come up with as many different possible uses for the interface you can think of, and implement them as far as you can go. Whiteboard the rest, and it should become clear what's missing. I'd say for a given "missing member", if you don't hit it within 3-5 iterations, you probably won't need it.
Version Numbers.
Define a "Complete Interface". Call it version 1.0.
Fix the problems. Call it version 2.0.
They're separate. They overlap in functionality, but they're separate.
Yes, you increase the effort to support both. That is, until you deprecate 1.0, and -- eventually -- stop support.
Just make you best reasonable guess of the future, and if you will need more create second version of your interface.
You cannot do it in a one-shot release. You need feedback.
What you can do is first make a clean interface that provide all the functionalities your library should provide; then expose it to your user base for real-world usage; then use the feedbacks as guide to update your interface -without adding features other than helper function/classes- until it starts to be stable on the interface.
You cannot rely only on experience/good-practice. It really helps but it's never enough. You simply need feedback.
Make sure the interface, or the interface technology (such as RPC, COM, CORBA, etc), has a well-defined mechanism for upgrades and enhanced interfaces.
For example, Microsoft frequently has MyInterface, followed by MyInterfaceEx, followed by MyInterfaceEx2, etc, etc.
Other systems have a means to query and negotiate for different versions of the interface (see DirectX, for one).
Our company is currently writing a GUI automation testing tool for compact framework applications. We have initially searched many tools but none of them was right for us.
By using the tool you can record test-cases and group them together to test-suites. For every test-suite there is generated an application, which launches the application-under-test and simulates user-input.
In general the tool works fine, but as we are using window handles for simulation user input, you can't do very many things. For example it is impossible for us to get the name of a control (we just get the caption).
Another problem using window handles is checking for a change. At the moment we simulate a click on a control and depending on the result we know if the application has gone to the next step.
Is there any other (simpler) way for doing such things (for example the message queue or anything else)?
Interesting problem! I've not done any low-level (think Win32) Windows programming in a while, but here's what I would do.
Use a named pipe and have your application listen to it. Using this named pipe as a communication medium, implement a real simple protocol whereby you can query the application for the name of a control given its HWND, or other things you find useful. Make sure the protocol is rich enough so that there is sufficient information exchanged between your application and the test framework. Make sure that the test framework does not yield too much "special behavior" from the app, because then you wouldn't really be testing the features, but rather your test framework.
There's probably way more elegant and cooler ways to implement this, but this is what I remember from the top of my head, using only simple Win32 API calls.
Another approach, which we have implemented for our product at work, is to record user events, such as mouse clicks and key events in an event script. This should be rich enough so that you can have the application play it back, artificially injecting those events into the message queue, and have it behave the same way it did when you first recorded the script. You basically simulate the user when you play back the script.
In addition to that, you can record any important state (user's document, preferences, GUI controls hierarchy, etc.), once when you record the script, and once when you play it back. This gives you two sets of data you can compare, to make sure for instance that everything stays the same. This solution gives you tests that not easy to modify (you have to re-record if your GUI changes), but that provide awesome regression testing.
(EDIT: This is also a terrific QA tool during beta testing, for instance: just have your users record their actions, and if there's a crash, you have a good chance of easily reproducing the problem by just playing back the script)
Good luck!
Carl
If the Automated GUI testing tool has knowledge about the framework the application is written in it could use that information to make better or more advanced scripts. TestComplete for example knows about Borland's VCL and WinForms. If you test applications build using Windows Presentation Foundation has advanced support for this build in.
use NUnitForms. I've used them with great success for single and multi threading apps and you don't have to worry about handles and stuff like that
Here are some posts about NUnitForms worth reading
NUnitForms and failed DragDrop registration - problem of MTA vs STA
Compiled application exe GUI testing with NUnitForms
I finally found a solution to communicate between the testing-application and the application-under-test: Managed Spy. It's basically a .NET application build on top of ManagedSpyLib.
ManagedSpyLib allows programmatic access to the Windows Forms controls of another process. For this it uses Window Hooks and memory-mapping files.
Thanks for all who helped me to get to this solution!
Managed Spy does not provide a solution for compact framework applications.
The company Jamo Solutions (www.jamosolutions.com) meets the requirements for automation testing on mobile devices, including .net compact framework applications.