at java.lang.Class.forName0(Native Method)
Web apps need a servlet environment to run; a command line will not do. For unit tests involving servlet code you may get away with mock objects.
But let's take a step back: how can trying to debug an issue with a web app take a whole month? If the debugger built into the IDE (assuming you're using one) is too cumbersome, try a standalone one like JSwat. I've been using that to debug apps running on Tomcat, and it works fine.
The JDBC issue means the JDBC driver is not in the classpath. You need to include the appropriate jar file in whichever way is appropriate for however you run the code. If that's on the command line, something like "java -cp .;mysql-connector-java-5.1.47.jar JDBCExample" might do the trick.
There are actual servlet test frameworks. Or you can launch a webapp server with debugging enabled and attach a Java debugger to it.
The best way to test a servlet, however, is to move as much of the code as possible into POJOs and test the POJOs. Stuff that requires actual access to HttpSession, Servlet Request and Response objects, JNDI, and other JEE facilities can't be tested that way, but at least you can test your business logic without the slow cumbersome business of launching a servlet framework.
And servlets should not be obtaining JDBC drivers in any case. Connection pools are more efficient and more portable.
Bjoke: A "Bully Joke". A Statement or action made with malicious intent - unless challenged. At which point it magically transforms into "I was just funnin'" or "What's the matter, can't take a joke?"
It is also an anti-pattern to be being too much work in the servlet itself. If you delegate responsibilities to other classes that do not depend on the servlet environment to run, they are not only more testable, it's just better design.