How to choose your IDE for development or test automation

As an automation tester, we spend a lot of time playing around the code, debugging it and reusing it. It’s important to have a good IDE (integrated development environment) where you can save a lot of time while writing code for your automation script.

Although the criteria for selecting the IDE is common for every language. It also depends on the personal preferences, and the kind of requirement one have in their project. In this blog post , I will talk about how to choose your JAVA IDE for Selenium WebDriver test.  An IDE should have following capabilities

  • Little configuration
  • Flexible
  • In-built plugin and build deployment support
  • Smart enough in code completion (most important)
  • Powerful, smart debugging

I have recently started working on a new selenium java project.For me it was not that hard to choose as I had most of experience using Eclipse from my previous projects and no experience using Netbeans and IntelliJ at all. This time I have thought of doing  experiment by using some other IDE

I was a big fan of Eclipse until I figure out the capabilities of IntelliJ IDEA. I have used IntelliJ IDEA community edition and following are some awesome features I have identified which I didn’t notice in Eclipse-

  1. It provides auto-suggestions while reusing variables, keywords and out of box method highlighting
  2.  If you have used some code for which reference is not added, it will suggest you to find maven info and add that in to pom.xml
  3. There is no need to create work space, you can start using/building any project from anywhere
  4. It has in-built support for identifying the possible plugin which can easy user’s work and will suggest you to install that (e.g. if you are using feature file in code , it will suggest to use cucumber plugin automatically)
  5. It has inbuilt ANT, Maven and Gradle support, while creating a java project in IntelliJ it automatically create Gradle, Build.xml and Pom.xml files
  6. It provides inbuilt Git, SVN, TFS support without installing any additional plugin

In a nutshell, conclusion is –

  • Eclispe – Very flexible, not very smart in code completion
  • IntelliJ IDEA – flexible, powerful, best code completion, smart,user-friendly
  • NetBeans – user-friendly, good for JAVA Enterprise beans projects

Current Market trend

According to a recent report by SoftSys the most used IDE by Java developers is Eclipse, which is open source and free to use. The next one is IntelliJ followed by Netbeans. Thus, more often than not cost can be one of the factors, specially if there is not much difference in features between different IDEs. From the perspective of a beginner almost all the IDEs seem identical in terms of their feature set, however, I am sure there are many differences in the details of how those features are exposed and how convenient it is to use them. So, is it just a matter of preference that some people like Eclipse and others like IntelliJ-


According to a recent survey, when people directly asked about choosing the IDE, here is what there response was –


So it’s very clear that as Agile is the new SDLC where all part of software development are aggressively done, so its better to have a powerful and smart IDE for development and save our time. 🙂

How did you choose your current IDE? What are the features that matter when deciding on an IDE? How much would you be willing to pay for it? Do let me know of your thoughts in the comments discussion.

Happy coding 🙂



Symptoms that your mobile automation is going to fail

Smartphone users are increasing every day and mobile world is growing so rapidly. People now share and access mobile apps more frequently than web apps.

Now talking about their creation, release cycles are so quick that you have to do a lot of work in testing product and that too should be quick. What choice we left ? Automation!. But are we really utilizing that in good manner or we are just making simple things too complex by introducing automation.

Based on my experience their are few symptoms which indicates that you are going towards failure in mobile automation. Agenda for sharing this info is to make you enable in judging whether you are going on right track or not.

So be aware of following 10 symptoms which might lead you to failure if you will not find alternative for them-

  1. Deploying the build (APK/IPA) is a manual process– If you are still doing it manually, stop it. Mobile automation should be as smooth as automating a web app and accessing it through a browser. To speed up the process this part of automation should be automated. There are several tools e.g. Jenkins, Team City. You can refer to my blog Continuous integration with Jenkins in 5 minutes for Continuous integration setup.
  2. No Process where test can execute 24/7 – In the agile world, release cycles are too quick and a tester hardly get some time to perform Regression, functional testing for each feature. You should have a process where your automation test can be triggered anytime and can give you quick validation results. You can achive it by setting up your own mobile devices cloud, or you can use existing paid services like Saucelabs, Testdroid cloud etc.
  3. Scrolling the device screen is co-ordinate based – If this is the case it is very hard to stable your test. As an automation developer, our primarily goal is to make sure that a test can successfully executed on any device of any size. So make sure all actions are object based rather than co-ordinate based. your script might not work for a device with different size.
  4. Wasting more time in stabilizing test rather than building them – It happens when we start creating script, we don’t really realize the factors like – locator strategies, target devices, screen sizes, complex actions involved. As a result, after certain point we waste our time in making current script stable and cant really look forward for new creation. So advice is before starting a project do a little bit of POC(proof of concept), identify the complex situations and take care of them from the starting itself.
  5. You can’t remember the last time when your tests ran successfully – I have seen such situations that when people have small numbers of cases, they have a control to easily identify the false failures and modify the script accordingly. then slowly false failures keeps growing up as the number of cases increases. I would say don’t let you get into that situations. Take each false failure seriously and try to handle all exceptions, so that you can have confidence in your scripts when it comes to releasing the app.
  6. Using indexes at too many places to identify the elements on screen – If you had worked on selenium, you might related when we create xpath based on location in html DOM, It is similar to that. Avoid using indexes in your locators. Mobile app web views, text box’s positions might change in future and you will again end up with modification of scripts.
  7. Using Image recognition or OCR extensively for identification – I have seen many times, people uses OCR or image based technique for identification of elements on screen. Chances of changing the UI design in mobile app are very high. Sometimes not the design but the images might get changes with minor pixel size changes and you need to replace all images for image based identification.
  8. Working for several months but have only dozen cases – A manual tester always try to create test-cases where he can achieve coverage in minimum cases, which result in few complex cases. When we take them for automation, we don’t really divide in to many smaller meaning full cases and start creating complex work flows. I suggest to break cases in smaller one, so that by using parallel execution you can minimize the execution time and get the more effective visibility in terms of coverage. So its good to have many small test scripts rather than few complex scripts.
  9. Running the same script on different size devices, never works on first try – Primary part of testing a mobile app is to test it across multiple devices and screen sizes. If this is not happening in single attempt, means you are not really taking care of all possible devices and screen sizes. You end up modifying your script as soon as you run the script on some new devices. So its advisable to be aware of device scope and functionality future in advance. Be in touch with business analyst is very important
  10. You are not controlling the targeted devices and versions – This is one of the most important aspects in terms of infrastructure for mobile script execution. As an automation engineer, you should be responsible for handling devices and their versions, installing apps in those devices. If someone else is doing it then you should be in sync with that team.

If you are facing anyone of above mentioned problem, start implementing best alternative. Lets not hamper your app quality and focus on being efficient in testing. Hope these point will help you.

If anyone has gone through some other complex situation in mobile automation, feel free to add your symptom in comment 🙂