I have a large piece of Java software that I am looking to add tests to for a new module. The new module involves running external applications and handling the results. The external applications are not something I can modify. In order to get results, these external applications need to be able to access and modify 2+ remote machines. Once they make those modifications, that machine is no longer in a valid state for more testing. My current application already includes JUnit tests, so it would be nice if I could write the new tests in JUnit as well.
My question: Is there a know technique for this use case? I know I could hack together some kind of solution using Vagrant, where machines are started up and torn down in the setup and teardown blocks of JUnit, but that seems like it could be hard to maintain, would require the tests to be run serially, and would be very, very slow.
EDIT: Removed the word "unit" because it was significantly sidetracking the question.
Related
I'm looking for a way to test the different functionality of my JavaEE server application. I first tried to do it with Junit and TestNG, but building the different scenario was too tedious.
What i'm searching is a tools that will simulate an user using my server application trough his browser, and then once this scenario is established i could check the output and verify if it's working.
Here an exemple:
An user connects to the server, the server application interface is displayed.
He executes the functionality to modify his personal datas
He modifies the different that he want to change.
He saves the modifications.
Then what i want to check is the actual state of the data in the database.
What i need is something that will simulate the action he did with his browser like i said above...
I've read different article about different tools that could do the works but i'm not sure because i don't really know what to type in google.
I discovered Jmeter (that is not working with my application because of web socket) and the Grinder.
The Grinder seems to be interesting but most of the things i've read about refers to it as load testing tools, which is not what i'm looking for.
Can someone experienced tells me if i can do what i want with the Grinder ?
You can use scripting tools like: Sikuli(Record Playback & Scripting) or Automa (Component Identification Scripting)
The most popular tool currently is Selenium. It will certainly do the job. I would also mention Geb because it provides more convenient API when compared to Web Driver.
I'll also let myself to give an advice, although it doesn't relate directly to your question.
If your project is big enough (4-5 teams over a couple of years can deliver a lot of code), you should think what to automate.
These tests can be very heavy both in terms of CPU load and in terms of time.
So if you'll rely ultimately on these tests, your build will run ages and will be potentially unstable.
So these tools should be used only to complement unit/component and integration testing that should exist anyway and they will use completely different tools.
Also in UI, consider using various testing techniques that would test only the UI side (mock the server endpoints and so on).
We've been working on a quite specific coding project recently. What we want to do is:
Use Java applications to do tasks impossible (or at least very diffucult) to accomplish in PHP
Control those Java programs with Joomla 3.0
We've found out that there is support for PHP Scripts in Joomla by using this extension or we could create our own module by using this.
My question is: Is there a way to call programs / execute commands in a more practical manner than using the PHP functions shell_exec() or exec() or using popen()?
Especially since these Java programs will run under a different user (on a Windows Server ...).
Thanks in advance!
Do not use such components. This is dangerous no matter what creator says. I'm Joomla extension developer and believe me it can ruin your application and make more problems and benefits. Depends on what you want to archive and how big will be your project you have few possibilities:
1. Create component that will execute commands
Something similar to what U did but based on custom created component. Its fastest and cheapest way. Problem starts when your Java application will use more resources then website (interface). So its more like good solution for start.
2. Create component that will contact application written in Java via API
This is good solution if your Java application use a lot of resources. You can run it on several servers, manage servers load so clients gets results faster etc. This gives you many possibilities, flexibility but is
harder to implement and will cost more.
3. Just use applet running on clients computer (if your application allows it)
Simple, effective, costs less but also can be impossible depending on what tasks application have to run.
I am basically practicing with Java socket programming by building client and server (not necessarily HTTP server). In brief, the clients are sending request through sockets to server and server adds requests to task queue. The thread pool initially has certain number of threads and each free one is assigned to one runnable task in the task queue. My web server also has a simple storage that stores and retrieves data from a file from disk. In this project, I have to take care of several concurrency issues.
Basically, I have to build client, server, thread pool, handler, storage. However, I want to test thoroughly in a good systematic way (unit test, integration test, etc.). I don't have much experience in testing so I am looking for pointers, methodologies, frameworks, or tutorials. (I use Ant to automate building, and initially consider JUnit and EasyMock for testing)
Before testing, I'd start by coding some rough and ready prototpye code. Just to see it working and to get a feel for the APIs I will be using.
Then introduce some unit tests with JUnit (there are other frameworks but JUnit is ubiquitous, and you'll find plenty of tutorials to get you started).
If your object needs to interact with some other Objects to complete it's tasks, then use mocks (EasyMock or whatever) to provide the interaction - this will probably lead to a bit of re-factoring.
Once you are happy, you can start to look at testing how your Objects interact, you can write new (integration) tests that replace the Mocks with the real thing. Greater interaction results in greater complexity.
Some things to remember
trivial methods aren't worth testing (e.g. simple accessors)
100% coverage is a waste of time
any test is better than none
Unit test is easier to achieve than integration test
Not all tests are functional
Testing multi-threaded applications is hard
There is a book on how Google does testing. Basically they don't write tests until something looks viable. They have engineers who advise on how to structure code for testing. The point is:
Runnable code is the goal
Tests add to that goal, but do not replace it
Writing code that can be tested is a learnt skill
I am responsible for a number of java application servers, which host apps from different developers from different teams.
A common problem is that some app is sent that does not work as expected, and it turns out that the app was developed on some other platform, i.e. openJDK on winXp or 7, and then deployed to Linux running Oracle JDK, or vice versa.
It would be nice to be able to enforce something up front, but this is practically not possible.
Hence are there any techniques to detect problems upon deployment I mean, without the source code, by scanning the class files?
If that is not possible, what is the tool I can use to send to the developers so they can identify from their source code what incompatible they have relied upon?
It's not possible to detect all such problems in a totally automated way. For example, it is extremely difficult to detect hard coded pathnames which are probably the single biggest issue with cross-platform deployments.
My suggestion would be to compensate for this with more automated testing at deployment time.
For example, in a similar environment I used to insist on deployment test suites: typically implemented as a secure web page that I could navigate to as the administrator which would run a suite of tests on the deployed application and display all the results.
If anything failed, it was an immediate rollback.
Some of the tests were the same as the tests used in development, but some were different ones (e.g. checking the expected configuration of the environment being deployed into)
Obviously, this means you have to bundle at least some of your test code into your production application, but I think it is well worth it. As an administrator, you are going to be much more confident pushing a release to production if you've just seen a big screen full of green ticks in your staging environment.
I am new to a project where developers still share code by sending files by mail.
We are using eclipse and cvs.
Developers from offsite send there code for reveiw to onsite where other developers take files one by one from there mail and replace in eclipse. It is ok for 2 or 3 files. But as the files keep on increasing this task really becomes a pain.
We cannot put the source files into the cvs as untested code from offsite can crash our build server.
Here my question begins:-
What can be the better ways to share code?
We dont want to create branches for each change because in this case we will end up with 10-12 branches everyday.
Code should be tested via continuous integration, especially in your situation where your programmers are scattered literally across the world. Your offshore people should be using unit/integration testing to insure that they don't break the build. You should institute process where before they finish for the day, they verify the integrity of the build.
If they are not, they are not worth the money you are paying them.
I suggest you give the offsite developers the ability to perform the same test as your build server. There is no reason they should be sending you code which they cannot test (or test that it at least runs without crashing).
Is there any reason they cannot access your systems via VPN. That way they can test the code via your's or a second build server and merge the code themselves.