This article presents practices to write more testable code with many examples in java, going a step further than just TDD.
Duncan Thomas Blogs about how to handle Dynamic Elements with LiquidTest, “In this blog post I will explain a small but important feature with an example. This feature is a small check box you see at the bottom of your browser when recording a test with LiquidTest, called Dynamic Element.”
The idea of driving development with tests has been popularized by the agile development movement. The fact is that testing and coding are inseparable components of software development. We get the best results with testers and programmers work closely together. How can we deliver real value to the business frequently? How can we know how much testing is enough? Let’s look at how testers and programmers collaborate to produce high-quality software.
This article takes the form of a tale to explain the differences between the different "driven development" approaches… and makes us think why there are so many of them?
Responsibility driven design is an approach that helps you shift focus from object state to interactions and responsibilities. This article shows how test driven development with mock objects facilitates responsibility driven design and drives you towards a more cohesive, loosely coupled design. Examples in Java.
This is a course that I teach through Net Objectives, Inc. The topic is database agility and, of course, TDD is a central area of concern.
This article shows how the behavior driven development can be applied to database development and how it can be used to develop and design databases in an iterative and incremental way, writing code and test in the same time.
A practical guide on when and how to outsource some of your software testing activities.
This article describes a xUnit pattern called ‘Own Library Interface’, which enables TDD for classes which seem not testable before. Especially TDD beginners can benefit from this pattern.
Acceptance test-driven development is what helps developers build high-quality software that fulfills the business’s needs as reliably as TDD helps ensure the software’s technical quality.
This article gives an overview of OpenUP and explains how it relates to both RUP, from which it received its foundation, and agile methods, from which it incorporates their best practices.
Migrating to Agile is more than changing your process. It also requires a change in culture. For most companies changing culture is the most difficult part. I believe this is true for several reasons. These issues should be addressed in two ways. First, you want to address the culture needs of each group head on. We will lay out a game plan for obtaining support from line management, the team, the individual and executive management.
High-quality usability of mobile applications can be a winning competitive advantage in the today’s software market.
Nonetheless, BugHuntress QA Lab experience in independent software testing showed that high-quality user interfaces occurred in about 70% of desktop applications, while a similar number for mobile applications is about 40%.
This article covers the following topics:
– What usability is in brief;
– Basic standards of the user interface;
– Mobile standards;
– Mobile interface peculiarity: left-handed mode; speed vs. satisfaction; landscape mode;
– General problems of mobile usability;
– Successful solutions;
– Automation of usability testing;
– Independent usability testing services.
I firmly believe in the principles of Lean and Agility. However, the practices we’ve refined for Agile software development do not translate well from the world of programming to databases.
This is part of a series of articles in which I investigate why.
As a software testing consultant and musician, I meet a lot of skilled testers who do amazing work. Through experience and a lot of trial and error, they have developed skills they can’t easily explain. Unfortunately, with software testing, there aren’t as many obvious avenues for skill development as there are for musicians. Many software testers don’t realize that there are learnable exploratory testing skills they can develop to help them become even more valuable to software development teams.
The increasing popularity of agile development methods is putting new demands on the traditional CM discipline. A working CM environment is essential for the rapid nature of agile development methods, but the CM process and the CM role has to be adapted to the present evolution of software development methods as well as automated tools. This article discusses lean principles and agile values within a CM scope and also introduces a method to classify the CM discipline in relation to development method and level of tool automation.
Earned Value Management (EVM) is a well known project management technique which measures the integration of technical performance, cost and schedule against planned performance within a given project. The result is a simple set of metrics providing early warnings of performance issues, allowing for timely and appropriate adjustments. In addition, EVM improves the definition of project scope, and provides valuable metrics for communicating progress to stakeholders. The information generated helps to keep the project team focused on making progress. AgileEVM is a light-weight, and easy to use adaptation of the traditional EVM techniques which provides the benefits of traditional EVM in Agile projects.
OpenUP is a lean Unified Process that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development. It is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project types.
Author: Per Kroll
Published: IBM developerWorks, September 15, 2007
For many years now, developers have had the upper hand when it comes to Test-Driven Development. No matter the language, there was a handy toolset to use – NUnit, JUnit, and xUnits for Perl, Python, Ruby, Delphi, and many others. But when it came time to implement the logic in the database, the options were few. Many people turned to developing their own unit testing solution – if they did unit tests at all.
Author: Cory Foy
Published: InfoQ, October 18, 2007
Unit testing can be difficult sometimes. In some cases, you need to refactor your code-under-test to make it more testable; in other cases, you need to apply some special techniques into your test code so that it can do what you want; and in the worst cases, you can’t think of any such techniques nor are able to refactor the production code and thus, don’t write any test at all. It’s in my experience working with many teams applying unit testing that they often have troubles writing tests for the data access layer (DAL), the UI layer, and multi-threading code, mostly because they are not aware of the techniques for doing that. That is not surprisingly difficult to understand though, business logic is much more intuitive and straight-forward to be tested and every single article or book out there will have examples writing test for the business logic firstly.
Author: Buu Nguyen
Published: September 30, 2007
It is clear that normal unit-tests represent individual cases only. A specification presents a complete description of a unit’s behavior. Unlike unit-test, sequence diagrams are perfectly readable but unlike sequence diagrams, unit-tests can easily be executed over and over again. The question is whether we could in some way combine sequence diagrams and unit-tests so as to create both the specification and the tests which would help to verify that the implementation fulfills the specification. The rest of this thesis tries to provide an answer.
Author: Peter Dimov
Published: University of Duisburg-Essen Master Thesis, September 28, 2007
There are two different kinds of automated tests recommended by the Agile disciplines. Unit tests, which are written by programmers, for programmers, in a programming language. And acceptance tests, which are written by business people (and QA), for business people, in a high level specification language (like FitNesse www.fitnesse.org).
The question is, how should developers treat these two streams of tests? What is the process? Should they write their unit tests and production code first, and then try to get the acceptance tests to pass? Or should they get the acceptance tests to pass and then backfill with unit tests?
Author: Uncle Bob
Published: Object Mentor, October 17, 2007
A common objection to TDD is this: "We don’t have time to write so many tests. We don’t even have enough time to write features!"
Here’s why people who say this probably already have enough time in the (real) schedule, they just don’t know it yet.
Author: Dean Wampler
Published: Object Mentor, September 2007
I’ve been a big believer in unit testing for years now, but was never serious about test-driven development (TDD) until a few months ago. It sounded like an interesting idea, but I didn’t understand why TDD practitioner were so zealous about writing the tests first. Why did it matter? I thought it was to ensure that some project manager doesn’t try to shave some time off the project by cutting the unit tests. Then I started doing some reading about TDD, poking around, asking questions, and trying it out myself. I discovered the real reason for writing tests first is that TDD isn’t about testing code, it’s about designing code.
Author: James Kovacs
Blogged: September 9, 2006
How do you write a test that fails because of lacking thread safety? Well, in this case I could start up some threads, make sure that they used the collection methods simultaneously and then assert that only one thread was allowed to do so at a time.
That turned out to be more easy to think than to code.
Introduces the two problems and their solution.
Author: The Vertical Slice
Published: September 14, 2007