In this eleven minute tutorial I'm presenting TDD with mocking technique using JUnit 4.x and EasyMock library. This is more advanced example of Test Driven Development - video tutorial on basics can be downloaded from here: Test Driven Development in practice.
Source code for this tutorial can be downloaded here (you can find also Eclipse project files in this bundle, so it's easy to import the project directly to your IDE - NetBeans users have to create a new project and add relevant classpath changes). Note that external.jar was built with Java 6 and thus you have to use at least JDK version 6 to be able to compile and run the example.
In Part 7 of My First Agile Project, I'll be talking about how we went about testing on our project. This part should stand alone if you haven't read the other parts but if you want to catch up, see the series Table of Contents at the end of this post.
Our project was to integrate and configure a new billing system to replace an old custom Oracle forms app. Doing an integration and configuration project presents a lot of challenges to testing, which I'll talk about below. In addition, like all projects, ours had a special set challenges. At first we thought the developers would do most of the real testing on the project with unit tests and verification of configuration changes by our Subject Matter Expert. The original plan included 3 sprints of testing at the end of the project just to make sure we had gotten all the needed functionality in during development. Looking back at this plan now, we all wonder how we could have so stupid. :)
Keep reading for more on how our plans went during development, what happened once we got into testing and why we're still doing testing now - 6 months past our original go-live date. As I said, testing on a configuration / integration project presents special challenges so I hope our adventures will help other teams avoid some of the pitfalls we encountered. If you're doing a similar project or have had different experiences you'd be willing to share with me and others, please post in the comments.
In this nine minute tutorial I'm presenting TDD way of developing software i.e. start from writing the test.
Many people often say that you should start from implementing at least interface and then start testing. In this tutorial I'm showing how easy it is to start writing unit test with nothing (not even an interface) i.e. only having the requirements. After couple of minutes I've got an interface, a working implementation and a full test suite.
This is what Test Driven Development is all about - software should be developed this way. Open this article to see the bigger player.
It is sometimes hard to start implementing new feature (or fix a bug) by writing an unit test even for a very agile and experienced developer, that's for sure. But it pays off and it usually turns out to be the easiest and the most efficient way. Besides this, developers have to decide what to test. "You should test everything!" some of you may say, but what does it mean?
Should I test all my JavaBeans (as Java is the language I mostly use I will give examples in this technology)? Should I test all my Data Access Objects? Should I test all toString(), equals(), hashCode(), etc. methods? Or maybe I should test only stuff where I "integrate" all those "low-level" components/classes?
I'll try to answer the question of what level of abstraction should be tested by your unit tests and why some unit tests may be considered a waste in this post.
I'm an agile developer because I write my code incrementally i.e. only what I need today. I usually start writing the code by writing Unit Test - it really works and it really helps me understand what should be implemented and how system should behave (I will leave the subject of convincing people, who are new to unit testing, to do "write-test-first" for a separate post). OK - I usually do this but sometimes it's difficult or I'm just too impatient to see the result and start with the implementation and write unit test later. How do I know which packages/classes/methods are tested and which are "not touched" by any single unit test? How do I know that my code is really used somewhere by other parts of the developed system? This is the work for code coverage tool.
I'd like to share my experiences about unit testing (using JUnit) Java servlets outside of the servlet container. Agile world tells us that we should automate as much tests as we can - it would be good if all aspects of the developed system are completely tested. We should test functional as well as non-functional requirements of our systems. But can all tests be automated? What is the REAL value of such tests? The reality brings us problems and pitfalls even experienced developers fall into. I will present such story regarding automated and manual testing of Java servlets.
The problem
Quite recently I had do develop some "proxy" servlets facilitating Ajax request from web browser to our middleware layer. We couldn't directly send Ajax requests because JavaScript security model doesn't allow to request data from other address than it was originally downloaded (similar restriction to Java Applet).
All right then, our servlets were not doing any amazing job (some input and output transformations were needed, however) but I made some bugs even having 100% test code coverage (used Cobertura 1.9).
RSS feed