副标题: Behaviour Driven Development with Rspec, Cucumber, and Friends
作者: David Chelimsky / Dave Astels / Bryan Helmkamp / Dan North / Zach Dennis / Aslak Hellesoy
出版社: Pragmatic Bookshelf
出版年: 2010-04-30
定价: USD 42.95
装帧: Paperback
ISBN: 9781934356371
作者: David Chelimsky / Dave Astels / Bryan Helmkamp / Dan North / Zach Dennis / Aslak Hellesoy
出版社: Pragmatic Bookshelf
出版年: 2010-04-30
定价: USD 42.95
装帧: Paperback
ISBN: 9781934356371
内容简介 · · · · · ·
Behaviour Driven Development is about writing software that matters. It is an approach to agile software development that takes cues from Test Driven Development, Domain Driven Design, and Acceptance Test Driven Planning.
RSpec and Cucumber are the leading Behaviour Driven Development tools in Ruby. RSpec supports Test Driven Development in Ruby through the BDD lens, keeping yo... (展开全部) Behaviour Driven Development is about writing software that matters. It is an approach to agile software development that takes cues from Test Driven Development, Domain Driven Design, and Acceptance Test Driven Planning.
RSpec and Cucumber are the leading Behaviour Driven Development tools in Ruby. RSpec supports Test Driven Development in Ruby through the BDD lens, keeping your focus on design and documentation while also supporting thorough testing and quick fault isolation. Cucumber, RSpec's steadfast companion, supports Acceptance Test Driven Planning with business-facing, executable requirements documentation that helps to ensure that you are writing relevant software targeted at real business needs.
The RSpec Book will introduce you to RSpec, Cucumber, and a number of other tools that make up the Ruby BDD family. Replete with tutorials and practical examples, the RSpec Book will help you get your BDD on, taking you from executable requirements to working software that is clean, well tested, well documented, flexible and highly maintainable.
RSpec and Cucumber are the leading Behaviour Driven Development tools in Ruby. RSpec supports Test Driven Development in Ruby through the BDD lens, keeping yo... (展开全部) Behaviour Driven Development is about writing software that matters. It is an approach to agile software development that takes cues from Test Driven Development, Domain Driven Design, and Acceptance Test Driven Planning.
RSpec and Cucumber are the leading Behaviour Driven Development tools in Ruby. RSpec supports Test Driven Development in Ruby through the BDD lens, keeping your focus on design and documentation while also supporting thorough testing and quick fault isolation. Cucumber, RSpec's steadfast companion, supports Acceptance Test Driven Planning with business-facing, executable requirements documentation that helps to ensure that you are writing relevant software targeted at real business needs.
The RSpec Book will introduce you to RSpec, Cucumber, and a number of other tools that make up the Ruby BDD family. Replete with tutorials and practical examples, the RSpec Book will help you get your BDD on, taking you from executable requirements to working software that is clean, well tested, well documented, flexible and highly maintainable.
作者简介 · · · · · ·
David Chelimsky is the lead developer/maintainer of RSpec. He has been developing software for nearly a decade, and exploring TDD for over five of those years. After three years training and mentoring agile teams at Object Mentor, David currently leads the software development team at Articulated Man, a Chicago based, interactive design firm. In his spare time, David likes to p... (展开全部)
David Chelimsky is the lead developer/maintainer of RSpec. He has been developing software for nearly a decade, and exploring TDD for over five of those years. After three years training and mentoring agile teams at Object Mentor, David currently leads the software development team at Articulated Man, a Chicago based, interactive design firm. In his spare time, David likes to play guitar, travel, and speak something resembling Portuguese.
Dave Astels is a Software Engineer at Engine Yard and has been involved with software and computing for over 25 years, recently having spent several years working exclusively with Ruby and Rails. Dave wrote the article that prompted Steven Baker to start the RSpec project.
Bryan Helmkamp is the lead maintainer of Webrat, a library to implement acceptance testing of a Ruby web application in a more expressive and maintainable way. Following three years of Ruby on Rails consulting, Bryan is now a software engineer at Weplay, a New York City-based startup building online tools for the youth sports community.
Dan North works with technology consultancy ThoughtWorks where he delivers software, coaches development teams, and hangs out at conferences. In 2003 and 2004 he developed the idea of Behaviour Driven Development and delights in the community that has grown up around RSpec and the enthusiasm and dedication of their core contributors.
Zach Dennis is a lead developer and co-founder of Mutually Human Software, a Grand Rapids, MI based web development consultancy. He has been enjoying Ruby for nearly 7 years and has contributed to several projects such as Ruby's standard library documentation, Ruby on Rails, and RSpec. In his spare time, Zach loves spending time with his wife, reading, listening to music, and running continuousthinking.com.
Aslak Hellesoy is the Chief Scientist of BEKK Consulting, a Norwegian business and technology consulting firm. In 2003, after seven years of Java programming, he fell in love with Ruby. He has contributed to dozens of open source projects and is the founder of the Cucumber project. Aslak likes to cook, ski, and travel.
Dave Astels is a Software Engineer at Engine Yard and has been involved with software and computing for over 25 years, recently having spent several years working exclusively with Ruby and Rails. Dave wrote the article that prompted Steven Baker to start the RSpec project.
Bryan Helmkamp is the lead maintainer of Webrat, a library to implement acceptance testing of a Ruby web application in a more expressive and maintainable way. Following three years of Ruby on Rails consulting, Bryan is now a software engineer at Weplay, a New York City-based startup building online tools for the youth sports community.
Dan North works with technology consultancy ThoughtWorks where he delivers software, coaches development teams, and hangs out at conferences. In 2003 and 2004 he developed the idea of Behaviour Driven Development and delights in the community that has grown up around RSpec and the enthusiasm and dedication of their core contributors.
Zach Dennis is a lead developer and co-founder of Mutually Human Software, a Grand Rapids, MI based web development consultancy. He has been enjoying Ruby for nearly 7 years and has contributed to several projects such as Ruby's standard library documentation, Ruby on Rails, and RSpec. In his spare time, Zach loves spending time with his wife, reading, listening to music, and running continuousthinking.com.
Aslak Hellesoy is the Chief Scientist of BEKK Consulting, a Norwegian business and technology consulting firm. In 2003, after seven years of Java programming, he fell in love with Ruby. He has contributed to dozens of open source projects and is the founder of the Cucumber project. Aslak likes to cook, ski, and travel.
喜欢读"The RSpec Book"的人也喜欢 · · · · · ·
按有用程度 按页码先后 最新笔记
-
第56页
_yuan_ (他们抽烟,不听音乐,是坏人。)
The Code You Wish You Had In my early days at Object Mentor I attended a TDD class being taught by James Grenning. As he was talking about refactoring a Long Method, he wrote a statement that called a method that didn’t exist yet, saying something like “start by writing the code you wish you had.” This was a galvanizing moment for me. It is common to write the code we wish we had doing... (更多)
(收起)The Code You Wish You Had In my early days at Object Mentor I attended a TDD class being taught by James Grenning. As he was talking about refactoring a Long Method, he wrote a statement that called a method that didn’t exist yet, saying something like “start by writing the code you wish you had.” This was a galvanizing moment for me. It is common to write the code we wish we had doing TDD. Per- haps we send a message from the code example to an object that does not have a corresponding method. We let the Ruby interpreter tell us that the method does not exist (red), and then implement that method (green). Doing the same thing within application code, calling the code we wish we had in one module from another module, was a different matter. It was as though an arbitrary boundary was somehow lifted and suddenly all of the code was my personal servant, ready and willing to bend to my will. It didn’t matter whether we were starting in a test, or in the code being tested. What mattered was that we started from the view of the code that was going to use the new code we were about to write. Over the years this has permeated my daily practice. It is very, very liberating, and results consistently in more usable APIs than I would have come up with starting with the object receiving the message. In retrospect, this also aligns closely with the Outside-In philos- ophy of BDD, perhaps taking it a step further. If the goal is to provide great APIs then the best place to design them is from their consumers.
2012-01-12 16:49:25 回应
-
第34页
无常之花盛开 (铜号吹响末人时代最后的黄金之阳)
Chapter 3 Describe Features with Cucumber ======================================== Write software matters. And what matters depends on the context. User stories as planning tool: - have business value - be testable - be small enough to implement in one iteration Triad of BDD: - Acceptance Test Driven Planning - Domain Driven Design - Test Driven Development (更多)Chapter 3 Describe Features with Cucumber========================================Write software matters. And what matters depends on the context.User stories as planning tool:- have business value- be testable- be small enough to implement in one iterationTriad of BDD:- Acceptance Test Driven Planning- Domain Driven Design- Test Driven Development (收起)2011-02-08 02:44:38 回应
-
第34页
无常之花盛开 (铜号吹响末人时代最后的黄金之阳)
Chapter 3 Describe Features with Cucumber ======================================== Write software matters. And what matters depends on the context. User stories as planning tool: - have business value - be testable - be small enough to implement in one iteration Triad of BDD: - Acceptance Test Driven Planning - Domain Driven Design - Test Driven Development (更多)Chapter 3 Describe Features with Cucumber========================================Write software matters. And what matters depends on the context.User stories as planning tool:- have business value- be testable- be small enough to implement in one iterationTriad of BDD:- Acceptance Test Driven Planning- Domain Driven Design- Test Driven Development (收起)2011-02-08 02:44:38 回应
-
第56页
_yuan_ (他们抽烟,不听音乐,是坏人。)
The Code You Wish You Had In my early days at Object Mentor I attended a TDD class being taught by James Grenning. As he was talking about refactoring a Long Method, he wrote a statement that called a method that didn’t exist yet, saying something like “start by writing the code you wish you had.” This was a galvanizing moment for me. It is common to write the code we wish we had doing... (更多)
(收起)The Code You Wish You Had In my early days at Object Mentor I attended a TDD class being taught by James Grenning. As he was talking about refactoring a Long Method, he wrote a statement that called a method that didn’t exist yet, saying something like “start by writing the code you wish you had.” This was a galvanizing moment for me. It is common to write the code we wish we had doing TDD. Per- haps we send a message from the code example to an object that does not have a corresponding method. We let the Ruby interpreter tell us that the method does not exist (red), and then implement that method (green). Doing the same thing within application code, calling the code we wish we had in one module from another module, was a different matter. It was as though an arbitrary boundary was somehow lifted and suddenly all of the code was my personal servant, ready and willing to bend to my will. It didn’t matter whether we were starting in a test, or in the code being tested. What mattered was that we started from the view of the code that was going to use the new code we were about to write. Over the years this has permeated my daily practice. It is very, very liberating, and results consistently in more usable APIs than I would have come up with starting with the object receiving the message. In retrospect, this also aligns closely with the Outside-In philos- ophy of BDD, perhaps taking it a step further. If the goal is to provide great APIs then the best place to design them is from their consumers.
2012-01-12 16:49:25 回应
-
第56页
_yuan_ (他们抽烟,不听音乐,是坏人。)
The Code You Wish You Had In my early days at Object Mentor I attended a TDD class being taught by James Grenning. As he was talking about refactoring a Long Method, he wrote a statement that called a method that didn’t exist yet, saying something like “start by writing the code you wish you had.” This was a galvanizing moment for me. It is common to write the code we wish we had doing... (更多)
(收起)The Code You Wish You Had In my early days at Object Mentor I attended a TDD class being taught by James Grenning. As he was talking about refactoring a Long Method, he wrote a statement that called a method that didn’t exist yet, saying something like “start by writing the code you wish you had.” This was a galvanizing moment for me. It is common to write the code we wish we had doing TDD. Per- haps we send a message from the code example to an object that does not have a corresponding method. We let the Ruby interpreter tell us that the method does not exist (red), and then implement that method (green). Doing the same thing within application code, calling the code we wish we had in one module from another module, was a different matter. It was as though an arbitrary boundary was somehow lifted and suddenly all of the code was my personal servant, ready and willing to bend to my will. It didn’t matter whether we were starting in a test, or in the code being tested. What mattered was that we started from the view of the code that was going to use the new code we were about to write. Over the years this has permeated my daily practice. It is very, very liberating, and results consistently in more usable APIs than I would have come up with starting with the object receiving the message. In retrospect, this also aligns closely with the Outside-In philos- ophy of BDD, perhaps taking it a step further. If the goal is to provide great APIs then the best place to design them is from their consumers.
2012-01-12 16:49:25 回应
-
第34页
无常之花盛开 (铜号吹响末人时代最后的黄金之阳)
Chapter 3 Describe Features with Cucumber ======================================== Write software matters. And what matters depends on the context. User stories as planning tool: - have business value - be testable - be small enough to implement in one iteration Triad of BDD: - Acceptance Test Driven Planning - Domain Driven Design - Test Driven Development (更多)Chapter 3 Describe Features with Cucumber========================================Write software matters. And what matters depends on the context.User stories as planning tool:- have business value- be testable- be small enough to implement in one iterationTriad of BDD:- Acceptance Test Driven Planning- Domain Driven Design- Test Driven Development (收起)2011-02-08 02:44:38 回应
书评 · · · · · · 我来评论这本书
热门评论 最新评论
"The RSpec Book"的论坛 · · · · · ·
| 哪位朋友有电子版, 可否分享下? | 来自panfu | 1 回应 | 2010-04-10 |
| 好 | 来自像梦 | 2009-07-08 |
以下豆列推荐 · · · · · · (全部)
- 深入Ruby/Rails系列 (RoBeRt)
- Ruby与Rails新手慎入 (阳志平)
- Reading List - 2011 (Yining)
- Ruby & Rails Books (404)
- Ruby On Zhendi (康德)
谁读这本书?
订阅关于The RSpec Book的评论:
feed: rss 2.0











