I've always found it easier to test with code when testing *anything*. So when I see large web applications, my first instinct these days is to build it with code. Recently I was testing a web app that had its own built in web server. Here are the steps I performed to get it up and running.
1. Get a VM and configure the application inside the VM.
2. Identify how the server can be started in debug mode. Usually these servers have startup scripts and shutdown scripts. Look at those. Sometimes you get lucky (like me) and find a debug mode startup script. The debug script will contain a line like this, which adds to your command line arguments while starting the server (some long java command)
-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
3. Verify that port 8787 is actually listening on the server, along with the other normal ports on which your web server runs (say 80,443 for e.g).
4. If you're using Virtual Box, setup port forwarding so that you can reach all the ports on the guest (80, 443, 8787) from the host. Netcat into the guest ports from the host and verify that things work properly.
5. Now download IntelliJ on your host and make sure it launches.
6. Import your project into IntelliJ directly from the svn/cvs/whatever repository using the 'Intellij Idea -> checkout from version control' at the start. You might have to install the svn/cvs/git client on your host as well, if you do not already have it.
7. Now configure a remote debugging configuration in IntelliJ. Here is a great StackOverflow post to help you do this. Give it a name 'remote_debug_project' or whatever you want.
8. Click Run. Debug remote_debug_project. The lower pane should open up and say something like 'Connected to the target VM, address: 'localhost:8787', transport: 'socket'
9. Set a breakpoint in code that you know will definitely be triggered. Maybe choose the 'login page' verify password function.
10. Visit the web page. Login. The breakpoint should get triggered now. Enjoy a more powerful way of testing web apps now.
If your clients give you source code and you can build it, I definitely encourage this way of testing stuff. The time you take to find stuff out with code is way way lower than with black box testing.
1. Get a VM and configure the application inside the VM.
2. Identify how the server can be started in debug mode. Usually these servers have startup scripts and shutdown scripts. Look at those. Sometimes you get lucky (like me) and find a debug mode startup script. The debug script will contain a line like this, which adds to your command line arguments while starting the server (some long java command)
-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
3. Verify that port 8787 is actually listening on the server, along with the other normal ports on which your web server runs (say 80,443 for e.g).
4. If you're using Virtual Box, setup port forwarding so that you can reach all the ports on the guest (80, 443, 8787) from the host. Netcat into the guest ports from the host and verify that things work properly.
5. Now download IntelliJ on your host and make sure it launches.
6. Import your project into IntelliJ directly from the svn/cvs/whatever repository using the 'Intellij Idea -> checkout from version control' at the start. You might have to install the svn/cvs/git client on your host as well, if you do not already have it.
7. Now configure a remote debugging configuration in IntelliJ. Here is a great StackOverflow post to help you do this. Give it a name 'remote_debug_project' or whatever you want.
8. Click Run. Debug remote_debug_project. The lower pane should open up and say something like 'Connected to the target VM, address: 'localhost:8787', transport: 'socket'
9. Set a breakpoint in code that you know will definitely be triggered. Maybe choose the 'login page' verify password function.
10. Visit the web page. Login. The breakpoint should get triggered now. Enjoy a more powerful way of testing web apps now.
If your clients give you source code and you can build it, I definitely encourage this way of testing stuff. The time you take to find stuff out with code is way way lower than with black box testing.
