We Keep Coding

What's the best approach for modular apps UI test scripts?

I'd like to know if any of You have experience in automation UI testing of modular-like apps. The whole app is like all typical CRM-related apps, where based on Your personal client needs You just put together some of the available modules (that have been predefined earlier) in order to provide all necessary functionalities.
If there would be "static" app built of all these modules put together then we could test it in a quite easy way, just going through all defined test classes, because we would know the behaviour/interactions between all these modules.
But in case we would need to test app behaviour while putting some of its random pieces/modules together in order to check if they work well, we would need some other approach.
If there's a solution, some recommended architect pattern or anything that can help me to perform such automation tests (using i.e. Selenium WebDriver)? Or does this kind of tests are even possible to perform using WebDriver library?
I'd be grateful if You'll share any of Your thoughts and experiences in this area.

I am working in that area and had a similar situation, here's what I learned from it:
Avoid creating UI tests if you can. UI tests are intended to test the look of your application and that's it. Business logic (like when I change that setting, the displayed data should change, etc.) should be tested in unit tests which are much easier to implement. Interaction between the modules should be covered as much as possible in integration tests.
If you still have functionality left over that needs to be tested, create a config file that contains the information about what customer has which modules enabled. In your test, read that config and if a test is not supposed to run, abort it.

In case some further researcher will look for the know-how solution for this case, we can just set some different test suites for each of app modules, and then we can check each suits for some certain condition met. If some suit won't meet this condition then we'll just skip this test suites. I.e we can get the app bundles.json file, which will most likely contain all information concerning app modules, and then we can just process this file to search for modules which are unavailable in current deployed app.
Look this as nice reference on how to achieve this: Introducing to conditional test running in TestNG

How to integrate JUnit into already developed application?

I'm very much new to JUnit. We want to integrate JUnit into our old and big Enterprise Java application(which has many projects associated with it) developed long back.We want to do it without touching java files and on framework level. Is it possible? If yes, please share me the links or information on how to do it?

I can't comment (yet) so here is my recommendation as an answer:
"Working Effectively with Legacy Code" by Michael Feathers covers all scenarios of testing / maintaining etc. of old, huge applications in a very readable way.

Why would you touch existing Java files for writing unit tests ( if you are ready to leave non-testable classes in your source as they are) ?
Isn't integrate JUnit means writing unit tests for existing classes using JUnit ( for which unit tests have not been written so far) OR is there any other meaning you intend too?.
We keep test classes written using JUnit in a separate source-folder so those don't mess with your existing code.
I don't see any concern here. Just add JUnit jar into your project's build path ( by including jar OR by adding maven dependency OR by adding Gradle dependency ) and start writing unit tests for your testable classes and you are done with your integration.
You might choose to not include source-folder-for-tests into your deployment build.
Sometimes in your old code, some classes might not be testable so you will have to tweak those a little if wish to cover those too.
Hope it helps !!

Where to learn about writing test cases?

I'm a CS master student. Throughout my studies I coded many course projects in Java. Soon I will graduate. When I explore some github projects I often find people organize their projects as /main and /test. I have never organized it in such a way, i.e. I always have my source code files without any test directories. I think that folder often contains what I think is called 'test cases' or so.
Since I will find a job soon, then I would like to learn about production-quality code.
My questions:
Why people often have that folder? What does it contain?
Can you provide me with a link to a good tutorial about the practice of testing in java? i.e how to do it? In a nutshell I wanna understand the idea of that /tests/ folder.

I often find people organize their projects as /main and /test
This is a matter of taste. Not 100% sure but at least maven projects have such organization.
From Maven: Introduction to the Standard Directory Layout, this would be the project layout:
src
main
java <-- your Java source code
resources
filters
config
scripts
webapp
test
java <-- your unit tests for Java
resources
filters
it
assembly
site
Why people often have that folder? What does it contain?
Usually, people write test cases to cover the code and check if the code works as expected. This is known as Code Coverage. Code coverage also serves as regression tests in case somebody makes changes in the code for enhancements like code refactoring.
The test cases you will find them usually are for Unit Testing. Depending on the type of the project, you could also find Integration Tests.
There is also Test Driven Development, or TDD, which is a practice whose basis is writing the test cases before writing the real code.
Can you provide me with a link to a good tutorial about the practice of testing in java?
This is off topic for the site. There are plenty tutorials on the net about this.

I don't have a separate folder for mine but usually people keep their Unit Tests in that folder. A unit test generally sets up "fake" data to test a given class so that a developer can easily debug any issues.

The reason people provide a /test folder is to contain unit test for their project.
There are really many ways of testing Java but JUnit is a very commonly used method of testing.

It is a good practice to write tests for your code. Begin with writing Unit Tests. I found this tutorial very useful. Writing test ensures that your code behaves as expected , corner cases are tested and adding new code in the future does not break existing functionality.
There are also mocking frameworks like JMock and Mockito that make writing stubs and drivers for your methods easy.
What is even more interesting is people prefer writing tests before they write the actual implementation. This approach is called Test Driven Development or Extreme Programming. Writing tests first ensure one already has a prep code or pseudo code for the methods in mind.

Java and android testing methodology

I have a question about technology or methodology out there that I can use to test my code fast & simply. Recently I came across the difficulty & frustration regarding to testing my code when I was working on an android project. Everytime when i wanted to test my code, i had to re-compile whole project again and wait for emulator to re-install application which at least takes 40~50 seconds just to check a bit of code working fine. Are there any way that I can compile or test just a small portion of code / 1 ~ 2 methods working without having to re-compile whole project every time? Also which one is the latest and most widely used among the industries?
=====================================
Additional question. I've done some research on JUnit testing of java but is JUnit what i'm looking for? or is it different kind of testing technology

you can make a search about Robotium. it provides you to do blackbox testing.
http://testdroid.com/tech/54/automated-ui-testing-android-applications-robotium

Maybe Robolectric is what You are looking for. You can use JUnit to test only java code that doesn't use methods from android sdk.

have you considered using AndroidTestCase? JUnit can only be used to non-android specific function, but this does the job for your Android-specific code.

There is a very detailed account for android testing available at:
http://developer.android.com/tools/testing/testing_android.html
This includes basic as well as activity testing and is built on top of JUnit.

For people that don't want to use Roboticum and such, but just stick with Eclipse built-in JUnit testing, this is what I would recommend:
Have three projects:
AndroidProject
AndroidProject.test
AndroidProject.test.android
In your AndroidProject.test project you only test Models, Controllers and such which exclusively uses Java-libraries. So no Android Logcats, Toasts, or things like Patterns.WEB_URL.matcher(url).matches()) [android.util.Patterns] (which validates a String URL).
In your AndroidProject.test.android project you test the Activities, Services, Model-classes that use Android libraries like the Pattern-validation mentioned above, etc.
To be able to use Eclipse Run As -> JUnit Test for your JUnit test project you have to do some set-up however, like removing the Android API from each individual Test class, using the junit.framework.Assert and org.junit.Test imports, etc. For a full step-by-step guide to reproduce what I have done to make it work, I refer to my own Stackoverflow-post that I've made:
JUnit Test Android classes without being forced to start the (slow) Emulator.

Building a test suite in a large existing Java code base

I am working on a web application with an existing code base that has probably been around for 10 years, there are ~1000 class files and ~100,000 lines of code. The good news is that the code is organized well, business logic is separate from the controller domain, and there is a high level of reusability. The bad news is there is only the very beginnings of a test suite (JUnit); there's maybe 12 dozen tests at most.
The code is organized fairly typically for an enterprise Java project. There is a stuts-esque controller package, the model consists of almost purely data objects, there is a hibernate like database layer that is largely encapsulated within data access objects, and a handful of service packages that are simple, self contained, and logical. The end goal of building this test suite is to move towards a continuous integration development process.
How would you go about building a test suite for such an application?
What tools would you use to make the process simpler?
Any suggestions welcome. thanks!

Start by reading Working Effectively with Legacy Code (short version here). Next I would write a couple of end-to-end smoke tests to cover the most common use cases. Here are some ideas on how to approach it: http://simpleprogrammer.com/getting-up-to-bat-series/
Then when I need to change some part of the system, I would cover it with focused unit tests (refer to the aforementioned book) and then do the change. Little by little the system - or at least the parts which change the most often - would be better covered and working with it would become easier.

I would create a few integration tests. Since they toch a lot of code, you probably will get an error when you screw up bigtime.
I wouldn't 'build a testsuite' as such, but rather before changing some part define a testset for it, and then go about changing it.
I would suggest looking into a test coverage tool (I don't code Java, so no clue what tool the best is for Java). While it does not tell you when you've tested enough, it does tell you when you tested too little ;)
Good luck!

If the project isn't already maven-ized I would do that. Also be sure to use a mocking framework like mockito. Hudson is a nice CI tool that integrates nicely with maven.

It looks like you are going to be writing both unit and functional tests, so JUnit might not be the best fit for this. Have you considered TestNG? Since you only have very few tests right now, you have the option to pick what's best for the job.