Although developers have been unit testing their code for years, it was typically performed after the code was designed and written. As a great number of developers can attest, writing tests after the fact is difficult to do and often gets omitted when time runs out.
Test-driven development (TDD) attempts to resolve this problem and produce higher quality, well-tested code by putting the cart before the horse and writing the tests before we write the code. One of the core practices of Extreme Programming (XP), TDD is acquiring a strong following in the Java community,
Say it like this: TDD trades a long time performing experiments in the debugger for a short time automating those experiments.
Put it entirely in terms of the programmer's unenlightened self interest.
but very little has been written about doing it in .NET.
Website from the books eXtreme Programming Explored/Installed/... ,
contains lots of information about processes, refactoring, ...
http://www.xp123.com/xplor/
-----------------------------------------------------
Mail.be, WebMail and Virtual Office
http://www.mail.be
... but it can be hard to find, especially in a large project. CPD uses (more or less) Michael Wise's Greedy String Tiling algorithm to find duplicate code.
From the summary:
This paper examines the challenges of testing enterprise
integration solutions and proposed a testing approach to tackle the
inherent complexities. This approach is accompanied by a framework
that makes integration testing more effective and efficient.
Additionally, the paper discusses the implications of Web services
and service-oriented architectures on the proposed testing framework,
and provides guidelines for the design of new integration solutions
to improve testability.
<http://www.hohpe.com/Gregor/Work/docs/TestDrivenEAI.pdf>
ABSTRACT
In this paper we describe techniques that we have found helpful for
adding unit tests to existing code that has been written without
tests. The paper presents some common coding practices that make unit
tests hard to retrofit, and why. For each practice we suggest minimal
refactorings to open up the code for testing.
<http://www.cwi.nl/events/2002/wtixp/papers/Freeman.pdf>
Perhaps bad and nonexistent documentation is to be expected. Ever seen good code
comments in a book? Ever heard a programmer being praised for well commented
code? The best you can hope for is a smattering of mind-numblingly dull and
ridiculously incomplete Word documents that are a year or more out of date.
We are used to the culture of making others dig thru the dirt. It is considered
a badge of honor to decipher how a piece of code works and should be used.
Read more on http://www.artima.com/weblogs/viewpost.jsp?thread=4183
-----------------------------------------------------
Mail.be, WebMail and Virtual Office
http://www.mail.be
According to a poll on Embedded.com, 68% of the respondents are using C for developing their embedded software. Why do embedded developers choose C over C++? Sure, there are some practical reasons to avoid C++, such as the availability of tools for your embedded processor. But another possibility is that embedded programmers do not know the advantages that an Object Oriented programming language can bring them. They may not know what the tradeoffs are when choosing to use C++ over C. This article describes some of the key reasons to use the OO features of C++ in your embedded applications and how to evaluate the cost tradeoffs.
Hello everybody, as a part of the NAME (Network for Agile Methodologies Experience) project we have prepared a research roadmap on agile methodologies.
OpenSTA is a distributed testing architecture that enables you to create and run
performance Tests to evaluate Web Application Environments (WAEs) and production
systems. It can be employed at all stages of WAE development as well as being
used to continuously monitor system performance once a WAE goes live.
Use it to develop load Tests that include an HTTP/S load element, known as
Scripts, to help assess the performance of WAEs during development, and to
create Collector-only Tests that monitor and record performance data from live
WAEs within a production environment.
OpenSTA enables you to run Tests against the same target system within both load
testing and production monitoring scenarios. This means that you can directly
compare the performance of the target system within these two environments.
www.opensta.org
___________________________________________________
The Proxy Sniffer v2.9 tool contains a unique, special proxy server with
integrated ssl tunnels to record unencrypted as well as encrypted HTTP(S) web
browser surf sessions. It generates - based on these recorded surf sessions -
automatically load test programs in form of Java source code, which can be
executed from any system that supports Java. By using a multi-processor UNIX
server as load source its possible to emulate up to 500 parallel web surf
sessions from one node. The product has also a build-in web server which allows
a graphical analysis of the measured test results.
http://www.proxy-sniffer.com/index_en.html
__________________________________________________
What is The Grinder?
The Grinder is a Java™ load-testing framework. It is freely available under a
BSD-style open-source license.
The Grinder makes it easy to orchestrate the activities of a test script in many
processes across many machines, using a graphical console application. Test
scripts make use of client code embodied in Java plug-ins. Most users of The
Grinder do not write plug-ins themselves, instead they use one of the supplied
plug-ins. The Grinder comes with a mature plug-in for testing HTTP services, as
well as a tool which allows HTTP scripts to be automatically recorded.
The Grinder was originally developed for the book Professional Java 2 Enterprise
Edition with BEA WebLogic Server by Paco Gómez and Peter Zadrozny. Philip Aston
took ownership of the code and reworked it to create The Grinder 2. Philip
continues to enhance and maintain The Grinder, and welcomes all contributions.
Recently Peter, Philip and Ted Osborne have published the book J2EE Performance
Testing which makes extensive use of The Grinder.
_____________________________________________
TestMaker (formerly Load) is a framework for building intelligent test agents to
check Web Services for scalability, performance and functionality.
http://www.pushtotest.com/ptt/downloads.html
-----------------------------------------------------
Mail.be, WebMail and Virtual Office
http://www.mail.be
The industry speaks positively about agile methods for software development (http://www.agilealliance.org) but hasn't yet applied those principles to the folks who do networking and infrastructure. It is overdue and I will take the first shot at some things that can make them more agile:
Keep network and infrastructure architecture to a minimum yet sufficient Develop organization-wide standards using an agile Enterprise Architecture approach for each area of the infrastructure including the network, data center, desktops, etc. Develop the future state of your enterprise architecture by making sure that you have only one of a particular type. For example, today you may have Windows NT and a 100Base T network, where tomorrow you may be running PDAs on 802.11b.
Maintain centralized control with decentralized operations Centralized control allows one to control costs, architecture and deployment standards. Decentralized operations simply mean that it does not matter where your IT people are located. This works in remote locations and outsourcing arrangements as well. Support personnel should always be placed as close as possible to the end customer.
Keep the mainframe holy and worship it daily In the age of distributed computing, disciplines are more important than ever. Some non-agile organizations have tried to migrate the mainframe discipline to client/server and browser based paradigms and have failed miserably. The disciplines found on the mainframe need to be customized and streamlined. The vast majority of mainframers grew up with useful methods for capacity planning, disaster recovery and had extensive change management. Today we need these time proven practices more than ever without of course the bureacracy.
Measure everything as you cannot manage what you do not measure In the days of the mainframe, they could measure everything related to their infrastructure and could tell you their system availability and other system qualities. Today, we do not collect these metrics under the guise that we are too busy. If an organization, calculates their uptime and holds people accountable the staff will figure out a way to run the systems more efficiently.
All production systems are equal in the eyes of architects The vast majority of enterprises today have mainframes, pc's, servers, pda's and so on and have taken non-agile approaches by organizing support groups around them. An agile organization will refer to these groups as simply "technical support" and make sure its staff is cross-trained on as many platforms as each can handle. Separating support along technologies results in inefficiencies, political problems, poor communications and piss poor morale. Reorganize based on maximizing efficiency and utilization not technology.
Worship users and give them praise The number one problem with failed projects is the lack of communication. Being agile requires one to prefer human interaction over processes. If your IT folks would rather string cable or play with VI then failure itself is wired. In many shops the communications issue is even more systemic in that they cannot adequately communication with their own peers. In the days of the mainframe, it was obvious who did what to whom. In distributed architectures, everything is spread across disparate tiers, technologies and even locations. The team should use agile methods and process that instill communication between IT and customers as well as amongst the various IT silos. This should be incorporated as part of the job description for all IT personnel.
Spread joy to people in foreign lands Many wise dinosaurs from the days when mainframes were king, sat in their lofty ivory towers meditating on how the world should be. The only time they would interact with common business folk is when the help desk would summon them with an usual problem. In other words, being reactionary was status quo.Todays economy requires IT to walk with the great unwashed and communicate with their users. Simply, IT needs to shmooze, sell and stand on their soapbox selling their wares. This is the first step in real reengineering.
XP is a symbiotic process: that is, you really need to do all of XP or none at all. There’s no in-between (with the possible exception of unit tests). The theory is that each of its individually flawed practices reinforces each other to produce something stronger.
Book Review: Extreme Programming Refactored
Ron Jeffries:
This book is painful to read for anyone who understands what XP is,
because the authors have gone to such pains not to understand, to
take out of context, and to distort.
It is dangerous to read for anyone who does not understand what XP
is, because the authors have gone to such pains not to understand, to
take out of context, and to distort.
Read more at:
<http://www.xprogramming.com/xpmag/books20030904.htm>
Upon entering the Software Factory it is immediately apparent to most visitors that things are very different.
The space is large, two stories tall, open and accessible. There are no walls and there are no cubes. The floor is painted cement and not carpeted. The space is broken into work areas by long folding tables that are clustered in groups of three or four. On each table sits a single computer and in front of that station sits two developers. In the Software Factory there is only one computer for every two developers. All software development is done in pairs.