Collaboration: At the Extremities of Extreme
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Kurt Christensen on Jan 02, 2007
Fit works by reading tables in HTML files, produced with a tool like Microsoft Word. Each table is interpreted by a "fixture" that programmers write. The fixture checks the examples in the table by running the actual program.FitNesse leverages Fit to provide a collaborative environment for developers and business users to create the acceptance tests which are then automated with Fit test fixtures:
FitNesse is an HTML and wiki "front-end" to FIT. While Fit makes it possible to run test tables, it does not itself provide an easy means of creating those tables or displaying the results of those tests. This is where FitNesse comes in. FitNesse makes it really easy to create, run, organize, annotate, and share Fit tests throughout a software development team.Fit and FitNesse are powerful tools for agile development teams. The issue, writes Gojko, is that the FitNesse documentation focuses on the Java implementation, which too often leaves .NET users to fend for themselves:
The online user guide deals only with the Java integration, and .Net implementation has a lot of subtle differences. Details of those specifics are scattered throughout the Internet, so I spent quite some time collecting partial information from blogs, but on the end, all the roads lead to the debugger. FitNesse.Net is, fortunately, open source, so I got the source code from Sourceforge and found what is really going on. As I could not find a complete, consolidated guide that explains how to start testing .Net code with FitNesse, I decided to write one myself and share it, so that others do not have to learn it from the debugger.Gojko's tutorial helps .NET users new to FitNesse get up and running, from download to installation to writing their first test fixtures. Anyone seeking information beyond this can find it in the book Fit for Developing Software, by Rick Mugridge and Ward Cunningham.
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
SCM best practices for multiple processes, releases & distributed teams
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
No comments
Watch Thread Reply