標籤歸檔:softwareengineering

Extreme Programming and Test-Driven Development

Extreme Programming
Extreme Programming (or XP) is a software engineering methodology, the most prominent of several agile software development methodologies.

Extreme Programming Explained describes Extreme Programming as being:
    * An attempt to reconcile humanity and productivity
    * A mechanism for social change
    * A path to improvement
    * A style of development
    * A software development discipline


Test-Driven Development
The goal of TDD is to write clean code that works.

What is Test-Driven Development?
Test-Driven Development (TDD) is a software development technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. Test-driven development is a method of designing software, not merely a method of testing.

In addition to normal “did it pass?” testing, you can go the opposite route. By testing your application where the weak points are, you can fix it before it ever becomes an issue.

Test-Driven Development Cycle
1. Add a test
In order to write a test, the developer must understand the specification and the requirements of the feature clearly.
2. Run all tests and see the new one fail
testing the tests
3. Write some code
It is important that the code written is only designed to pass the test; no further (and therefore untested) functionality should be predicted and ‘allowed for’ at any stage.

KISS
Keep It Simple, Stupid.
Everything should be made as simple as possible, but no simpler.
                    –Albert Einstein

You Ain’t Gonna Need It
‘You Ain’t Gonna Need It’(YAGNI), is a reminder for programmers that one should never add functionality until it is necessary.

4. Run the automated tests and see them succeed
5. Refactor code

Refactoring
A code refactoring is any change to a computer program which improves its readability or simplifies its structure without changing its results.
List of refactorings

    * Encapsulate Field(e.g. providing methods that can be used to read/write to/from the field rather than accessing the field directly.)
    * Extract Method (to turn part of a larger method into a new method. By breaking down code in smaller pieces, it is more easily understandable. This is also applicable to functions)
    * Generalize Type (to making more general or more abstract some subset of the traits of a specific type. An example of generalizing a type would be moving a method from a child to a parent class for common use by all the parent class’ children, not just the original child.)
    * Pull Up (moving a method from a Subclass into a Superclass. )
    * Push Down (moving a method from a SuperClass into a SubClass.)
    * Rename Method (changing the name of a method into a new one that better reveals its purpose).

The cycle is then repeated, starting with another new test to push forward the functionality.

"Test-Driven Development Mantra" is known as red/green/refactor where red means fail and green is pass.

Benefits
By focusing on the test cases first, one must imagine how the functionality will be used by clients (in this case, the test cases). Therefore, the programmer is only concerned with the interface and not the implementation.
It allows a programmer to focus on the task at hand as the first goal is to make the test pass.
Ensuring that all written code is covered by a test.

Limitations
A test-driven development is only as good as its tests.

Reference
http://en.wikipedia.org/wiki/Test-driven_development
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
http://en.wikipedia.org/wiki/Refactoring

Related Resources
Test::Unit – Ruby Unit Testing Framework
A Guide to Testing the Rails
Test Driven Design for Ruby and Rails
Ruby, Rails, Test::Rails Cheat Sheet

發表在 Ruby on Rails | 標籤為 , , | 留下評論