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 this tutorial I'm presenting Selenium IDE - a tool for recording and replaying functional tests of web based applications. I'm showing how to record a simple test, test for Ajax-enabled application and how to replay such tests in Firefox web browser. I'm not showing how to start Selenium tests from Continuous Integration server in this tutorial - this is a subject for separate post.
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.
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).
At the Agile Open Europe conference I participated in a discussion on the subject of acceptance testing. One of the open questions was how to match "traditional" customers with the agile idea of delivering a potentially shippable product every few weeks.
Different Types of Customers While some customers are delighted to receive a new release every month, there are others that don't even want to see or know about any of the intermediate releases. Some customers simply insist on working the traditional way. They hire a team of testers for a couple of weeks before the intended release date, and they require the development team to deliver one release candidate, just in time for the test period, and the team should then stop working on the system until the test team has finished testing.
Lately I noticed several discussion threads both offline and online (the most notable online one is in the leandevelopment Yahoo! group) focusing on the value of software testing, both automated and manual. The main discussion point as far as I can see it is in whether the testing is actually a waste that is unfortunately needed to cope with the insufficient practices and should eventually be eliminated.
Knowledge Source
Software development is always not a mass production, but a new product development - software engineers are not manufacturing goods, but rather make a design for a compiler to manufacture something nobody previously built.
I wrote about Acceptance Testing earlier and why it is a very important tool for agile development. In this post, I will talk about how we can make acceptance testing really agile. Actually, it's nothing more special than making Acceptance Testing a part of your Continuous Integration (CI) (an XP Primary Practice). Continuous Integration is the practice of merging, building, and testing code on a continuous basis (almost instantaneous basis).
Acceptance testing is a black-box testing performed on a software prior to its delivery. It involves running a suite of tests on a completed system (ref: Wikipedia). These test suites are made up of multiple tests or test cases. Each test case consists of a sequence of steps to perform which emulate the use case that is being tested; it also contains input data (if required) as well as the expected output. The result of a test case is either a pass or a fail.
Update: The users of some a bit exotic SDKs reported that they cannot build the example. The reason was the project file SampleTest.mmp. I updated it making the project file a bit redundant. Now example should be compilable on any S60 SDK.
CppUTest is a unit testing framework based on CppUnitLite and designed for the embedded systems usage. Lately it has been ported to Symbian OS used in Nokia S60 smartphones. The framework is xUnit compatible, extremely simple and easy to use. It can print the test results both to console and to a junit-like xml file (later I am going to investigate how well it can be parsed by standard junit output parsers).
Symbian extension. Usage example
Unfortunately, CppUTest package at the moment does not include a full-blown Symbian specific example and lacks support for such Symbian primitives as descriptors (Symbian strings) and leaves (Symbian exceptions).
The file attached to this post contains both. It is a simple and heavily commented example of using CppUTest in Symbian, that includes cpputestsymbianextension.h adding support for descriptors and leaves.
RSS feed
Subscribe on Kindle