Can we start by asking a serious question? How easy is it to find advice for novice Java programmers on the web? Whenever I look, I see tons of tutorials, books and resources for a programmer who is just starting out. At the same time, there is a ton of information on how to get a wide perspective on a large enterprise project: scaling your architecture, message busses, database interconnections, UML diagrams and other high-level stuff is well documented.
Not long ago, I inherited a bunch of spaghetti code sitting inside a big legacy enterprise application, and I found myself hoping that everything I needed to deal with was already there (and hopefully working properly). But when I needed to change something, how could I tell what will be affected? The side effects of any changes I make should be clear from the beginning. If only I could do unit tests AND see the ripple effect across the code too…
Well, I can. It’s called Mocking, and it lets you create alternative realities for your application to play through, without having any side effects or consequences in reality.
After the explosion of Github, where source code is located offsite, and the rise of cloud computing services such as Amazon Web Services, the next logical step is to move the build system itself to the cloud. We’ve talked about continuous integration before when we discussed the best Jenkins plugins that you want to install, how to visualize pipelines of the build jobs, and even created a report about how to get started and up to speed with Jenkins.
Are you keeping your code safe by unit testing with tools like JUnit, TestNg and Mockito? Unit tests let developers internally control the functionality and compatibility of their applications when they made changes to features, code or the environment.
In this latest report from RebelLabs entitled Go Away, Bugs! Keeping Your Code Safe with JUnit, TestNG and Mockito, we build on previous research and years of experience to deliver you over 30 pages of code, examples, suggestions and tips….
When it comes to Java, most developers either use JUnit or TestNG and Mockito for mocking up your unit tests. JUnit is the established de-facto solution, TestNG attempts to offer additional features needed for Enterprise applications, and Mockito comes to the rescue and offers powerful mocking abilities to your unit tests. But is the JUnit/TestNG + Mockito solution the best one?
For this post, I took some time to play around with another testing framework called Spock. Spock is a test framework for Groovy applications, however as a Java developer I wanted to know how well it did at testing Java code as well. So far, I’m impressed….
With this post, we round off this series on JVM languages–in the future, we hope to get around to other interesting programming tongues that we missed this time. The last one we checked out was Fantom, a bit of a move away from the traditional JVM langs, and in that spirit we will talk now about Clojure, a Lisp-like programming language that runs on the JVM.
In my previous article on unit testing, I showed you how to mock all the dependencies of a single Java class in order to isolate it from the rest of the system. This way the class under test is in a controlled environment where you can test its own business logic with nothing else in the way.
However there are some times where you should NOT use mocking during testing. These are the times where you are actually interested in the interface of this class with its dependencies. You zoom out from a single class and you want to test a component of the system which not only is based on multiple classes but it might also use other systems such as a database or a queue.
In my previous blog post Why Your Next Cloud App Will Probably Suck Without…Unit Testing, we gave an overview promoting the benefits of unit tests, and how these small, simple actions can make a big difference in getting bug-free, solidly-built applications out the door.
Every day, developers are the world use unit tests as an internal control on the functionality and compatibility of their applications when changes to features, code or the environment happen. Yet unit testing is sometimes a controversial topic among Java developers, with one side of the camp thinking that writing unit tests is a waste of time, and the other believing them to be an essential part of the software development process, and the way to ensure that your new app doesn’t, well, suck because it wasn’t checked properly…