Usually, when developing algorithms for android applications in eclipse, I used pure Java projects that would have a dependency set to the android project and could then run JUnit tests in the pure Java classes. This had great advantages since I could run my tests on my algorithms and logic classes really quickly without any deploying.
Could anyone tell me if it is possible (and how) to do something similar with android studio??
Thanks!
How about the gradle android test plugin?
("A Gradle plugin which enables good 'ol fashioned unit tests for Android builds." sounds like what you want)
Or maybe something like robotium / roboelectric.
I have an existing java application which is developed in Netbeans this is my first major development project so i didn't think about the use of log4j & junit in first place(A good lesson learnt). since now i am at the end of the project i miss these two . is there is any tool or jar which can create automated testing & logging with minimum effort ? I guess Adding log4j is easy but what about junit ?
There is nothing to say that you cannot use Junit after you have created a project. It means that you are not making use of test driven development, but there is no reason why that is an issue once you have already created your project.
I would recommend the netbeans tutorial on exactly how to do that:
https://netbeans.org/kb/docs/java/junit-intro.html
I'm trying to figure out the best way to automate the execution of and result recording of load tests. We currently use Maven; ideally the solution would be executed as part of the Maven project life-cycle, so that people do not need so spend time on effort setting up the tests.
It should save the output of the tests (e.g. as some files that could be committed into version control), and should have the sense to not compare tests run on a dusty x486 with a 8 core Sparc.
JMeter is another Apache project which is very well adapted for automation (you can control most things from the command line); there are also several plugins that you can use to integrate it into Maven. Personally, I think this is by far the best tool for this sort of requirement.
You still need to create the actual tests to run and decide which environment to use - but this will always be the case no matter which tool you choose.
Have a look here, here and here.
I currently have a Java application running on Google App Engine, but I want to add the features that the Python module's SearchableModel provides (for search features of course). Is it possible to run python code in the same project as Java code, just under a different version? If not, could they be two separate apps (current Java app and a new Python-based search app) running against a single datastore, but I don't think that is possible.
It is possible to run Python and Java applications on different versions.
From:
Last but not least: remember that you can have different version of your app (using the same datastore) some of which are implemented with the Python runtime, some with the Java runtime, and you can access versions that differ from the "default/active" one with explicit URLs.
Yes, you can write your app in Java and also have a separate version of your app running Python.
However, if the core of your app is already implemented in Java, you might want to look at the SearchableModel Python code, then consider implementing something to accomplish your goal in Java. The gist is that you could simply build your list of search-words and store them in a multivalued property (ie a list).
You should also check out the Building Scalable, Complex Apps on App Engine video. Depending on your use-case, moving the search-word list to an 'Index Relation Entity' might offer further improvements.
On large-scale Java/.Net Enterprise projects, does every developer need to have all the components/libraries/dependencies in their classpath/local development environment, in order to make it build?
Or are they divided up into smaller sections can be built in isolation (so that they don't need to reference all the dependencies)?
In other words: if they want to run the whole application, they need all the components; but if they are only running a subset of the app, they'll only need the corresponding subset of components.
Are large enterprise projects usually organized in the first way or the second way?
A possible organization is if you are working on a module of the whole project that is self-contained, but referenced by other modules (in other words, a leaf-node in the dependency tree).
Another organization is if you dynamically load classes that you use, you can build without having any of them in your classpath. To run it, your classpath only needs to access the ones that you actually load (there might be many others that form different parts of the project, that you don't load).
These are theoretical possibilities; but what's standard practice for enterprise projects, in... well, in practice?
I've expanded this to include .Net, because I think the same issues would arise there (DLL hell?)
There's a different answer to this question for every project out there. A few general points:
"running a subset of the app" is often not possible, as very few apps are modular enough so that each part of them can actually run independantly.
What you sometimes have is an app core that is always required, and modules built on that core that are more or less independant of each other.
The big difference is usually not between having vs. not having all components, but between having them as source code vs. having them as JAR files.
On large apps, developers typically have only the parts they're working on in source code and the rest as JAR files
If you need runtime modularization (i.e. components are loaded and unloaded on demand at runtime), that's what OSGi is intended for.
They may need only a subset to build, and another subset to run their tests, but because all dependencies of less-than-trivially-sized Java projects can very quickly become a nightmare to keep track of, Java developers have come to love developed a love/hate-relationship with their elaborate build systems, such as Maven, which manage their development environment for them.
For projects that do not use such a system, it is generally easiest to just include everything all the time. The trade-off is unnecessarily bloated development environments versus having to spend time to track down missing dependencies.
A good project structure will break down things so that you can run independent modules.
But in real life, most projects I've seen don't do this until someone gets fed up and takes initiative to break them down.
If you use a good dependency management infrastructure like Maven or Ivy properly, you can store compiled modules on a server and download these dependencies on an as-needed basis.
You can also get away with having many mock objects and services to help break down the testing dependencies on other product components.
I certainly agree with the comments that it would be "good" to separate things. But in practice, that's very rare.
Assuming that you must work in an environment which has not been separated, there's another organizational strategy, and it's what I've seen used. Since your question refers to both build and run dependencies, you don't appear to be talking about processes, but about classes and jars.
The simple solution for that is to have the complete set of built, integration-tested (or integration-test-ready, for that matter) dependencies up on a shared server.
Then developers build in their local environments the portions of the system on which they're working, using a classpath which references first their development and then the appropriate shared server.
Your question isn't very clear, but I think the answer is that every class your application needs has to be in the CLASSPATH or the class loader with throw a ClassNotFoundException.
That's true whether you're a solo developer or working on a larger, distributed team.
In my experience, applications are packaged one way. If you only want a subset, you have to package it as such.
If you mean test cases as something separate, those usually aren't packaged with production code.
In my opinion, it's not whether developers can work on a subset of the application, but rather managing the dependencies between the projects (think Eclipse projects) that make up the app. Often you might have a tree of such projects where one or more project can depend on other projects. In such cases it's usually the role of the upstream/common project to make sure downstream projects are not broken due to changes in this upstream project.
Think of it like this - let's assume you have a utils project where you put all the common/utility functionality for your application - this could be validation logic, string utilities, logging, etc. And you have a bunch of other projects that use classes from this utils.
utils
/ \
proja projb
In this case, the person working on utils should also have proja and projb on their development environment as any change to utils will break them. However if you're only working on projb then you might not have to include proja as you have no dependency to that project.