HN Books @HNBooksMonth

The best books of Hacker News.

Hacker News Comments on
Growing Object-Oriented Software, Guided by Tests

Steve Freeman, Nat Pryce · 11 HN comments
HN Books has aggregated all Hacker News stories and comments that mention "Growing Object-Oriented Software, Guided by Tests" by Steve Freeman, Nat Pryce.
View on Amazon [↗]
HN Books may receive an affiliate commission when you make purchases on sites after clicking through links on this page.
Amazon Summary
Foreword by Kent Beck "The authors of this book have led a revolution in the craft of programming by controlling the environment in which software grows.” --Ward Cunningham “At last, a book suffused with code that exposes the deep symbiosis between TDD and OOD. This one's a keeper.” --Robert C. Martin “If you want to be an expert in the state of the art in TDD, you need to understand the ideas in this book.”-- Michael Feathers Test-Driven Development (TDD) is now an established technique for delivering better software faster. TDD is based on a simple idea: Write tests for your code before you write the code itself. However, this "simple" idea takes skill and judgment to do well. Now there's a practical guide to TDD that takes you beyond the basic concepts. Drawing on a decade of experience building real-world systems, two TDD pioneers show how to let tests guide your development and “grow” software that is coherent, reliable, and maintainable. Steve Freeman and Nat Pryce describe the processes they use, the design principles they strive to achieve, and some of the tools that help them get the job done. Through an extended worked example, you’ll learn how TDD works at multiple levels, using tests to drive the features and the object-oriented structure of the code, and using Mock Objects to discover and then describe relationships between objects. Along the way, the book systematically addresses challenges that development teams encounter with TDD--from integrating TDD into your processes to testing your most difficult features. Coverage includes •   Implementing TDD effectively: getting started, and maintaining your momentum throughout the project •   Creating cleaner, more expressive, more sustainable code •   Using tests to stay relentlessly focused on sustaining quality •   Understanding how TDD, Mock Objects, and Object-Oriented Design come together in the context of a real software development project •   Using Mock Objects to guide object-oriented designs •   Succeeding where TDD is difficult: managing complex test data, and testing persistence and concurrency
HN Books Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this book.
Growing Object-Oriented Software, Guided by Tests is a bit old, but still a very nice book to read: https://www.amazon.com/Growing-Object-Oriented-Software-Guid...
I try to setup a feedback loop as soon as possible. I spend time setting up so i can do some simple action (hit a button, run a command, or automatically watch some files) to see if I'm on target it.

I found this saves immense time and keeps me on task pretty well.

This is from: - GOOS book https://www.amazon.com/Growing-Object-Oriented-Software-Guid... - https://www.youtube.com/watch?v=nIonZ6-4nuU

johnwheeler
Feedback loop as soon as possible... Absolutely, this!

Also, I've found setting up deploy to production as early as possible keeps you focused, prioritized, and eliminates a good bit of anxiety helping you produce better work.

tedmiston
Another good feedback loop is just using a REPL.

https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93prin...

I would not start with technology stack and build around them. You look at your use cases and build out. Pick your frameworks and databases judiciously and as late as possible.

Read: https://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html

Read: http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui...

[EDIT] Removed the unnecessary/unhelpful opening statement.

duiker101
Yes/No, depends on many factors IMHO. Mostly on the person/team that needs to build/use it.

We know nothing of OP's case so the best thing we can do is trying to answer his question instead of answering to go read some lengthy book.

OP might be in a team that needs to develop an API for a product that will be deployed to millions of people(I doubt it) or could be someone that just wants to know what is the current fashion to develop a CRUD application while learning a new stack that is up to date.

In the first case, you might want to learn more of the situation you are in and pick around that. In the second case, there is nothing wrong with just picking one and hacking away.

dommer
fair comment. I will add though, spring, or hibernate, or play, or [pick your framework here] will also require reading.
dtech
I think "JVM Web app that does CRUD" is sufficiently narrow to consider that your use case, and pick a technology based on that use case.
hluska
The OP listed the following requirements:

"simple CRUD app"

That is more than sufficient to pick a framework/database and start working. I'm not sure how many simple CRUD apps you have built, but the challenge tends to come when you put them in front of users who can't figure out the interface. Consequently, I'd argue to choose a framework quickly and get it in front of a user as fast as you can.

networked
For context, I already have a JVM application that handles the business domain. Adding a CRUD user interface (and, coincidentally, a database) is the next step I have in mind for its development. However, I didn't want to state those constraints in the OP because I wanted the answers to be broadly applicable.
dommer
you can look at this list of Java awesomeness.

https://github.com/akullpp/awesome-java

Or other awesome stuff at the parent project.

https://github.com/sindresorhus/awesome

untitaker_
Particular things have to be decided upfront. You can't just add an app framework as an afterthought to your code.
dommer
I'm unsure about that and I think it depends greatly on what is the goal.

You can very easily do DI without Spring. (yes I know Spring is more than DI) As the project grows you can simple add Spring if brings 'real' value.

You can defer the choice of data store very late in a project without hinder its progress.

I'm not anti-framework/tooling, I just want to make sure it is required before I add it.

Most, if not all, frameworks require some specific bootstrapping/configuration that is extra to the job at hand.

None
None
inglor
Just because uncle Bob says something doesn't mean it's true.

Frameworks and stacks provide templates for building CRUD apps. Building CRUD apps (read: database skins) isn't a big technological challenge most of the times anyway. So picking a stack that abstracts most of it for you could be a great help to only focus on the parts you care about.

Not every project requires astronaut architecture and grand design. Half the internet runs perfectly fine without these considerations.

Scaffolding a project through the tooling of a framework (tooling matters!) and having something up in a day instead of philosophical debates about your data is huge. Having something up in production super fast because you didn't stop to think about architecture is perfectly fine for 95% of software projects that are just CRUD.

dommer
My inclusion of these two reading resources were only meant as examples. The reader is still required to make their own mind up.

I haven't suggested astronaut architecture; the question didn't indicate the size/scale/importance either.

50% of the internet runs perfectly fine without consideration...wow! Have you looked at all the source code yourself to make such a ridiculous conclusion.

Tooling does matter, but I'm suggesting the point of focus to start with is the requirements.

Scarblac
He did start with the use case -- "a simple CRUD app".

That is sufficient to start looking for a framework, in my opinion. Cases where that is wrong aren't simple.

inglor
As a data point, 20% of the internet runs WordPress [1], think these people spent a lot of time thinking about architecture.

A lot of time the problem being solved is in fact simple enough and easy enough to solve without thinking about architecture, not everything is a hard problem - and there is nothing noble about solving things over and over.

The point I was disagreeing with was "Pick stacks as late as possible". If you have a large project by all means do that, if you're just building a REST API in microservice architecture, or you're building a blog or something that's fairly simple to model - you're perfectly fine picking a framework you like first.

[1] http://w3techs.com/technologies/overview/content_management/...

dommer
I'll skip the flame about WordPress developers as I don't know any, or, viewed their work.

If you think building micro service architecture can be done without consideration I'm lost for words.

The question–as I've been rightly reminded–was 'CRUD Web App in JVM'; furthermore, we now know that the domain part of the application is already done, so my comment is moot.

That just leaves CRUD, Web, and JVM.

michaelmcmillan
It seems to me that you intentionally misrepresent the argument to make it easier to attack. No one is claiming that Uncle Bob is always right or that an "astronaut architecture" is the correct design.

On a different note, I would also recommend to not start picking the framework or stack: Instead I would start by creating a couple of basic classes that represent the business logic.

I would also write tests for those classes. Furthermore I would probably introduce some repository classes that would interface with the database. Lastly I would try to find a library that handles HTTP routing - if the CRUD app was meant to have an HTTP I/O channel.

Not everyone wants to "go fast and break things" or blindly let their codebase depend on a third-party framework. This is usually what ends up happening when you don't think about architecture.

Check out the most popular Angular posts on HN this year [1]. Notice a trend?

[1] https://hn.algolia.com/?query=angular&sort=byPopularity&pref...

Retric
I would start by creating a couple of basic classes

How would you do that without deciding on a language/framework?

Suppose the goal is a shared calendar and message boards plus some way to buy ski passes. Doing this using SharePoint is going to be vastly different than Ruby on Rails.

Feb 02, 2015 · cessor on A Quiet Defense of Patterns
I felt that your comment speaks to me - I had a similar understanding a couple of years ago. In their book "Growing Object Oriented Software, Guided by Tests", Nat Pryce and Steve Freeman describe values and objects, *(Values in the sense of Value Objects in Evans' DDD)

> The confusion is, that both concepts are implemented by the same language construct: Classes

This made me think. In C# this statement is somewhat untrue, since you have structs that have value semantics (value equality). But why are there no other concepts within the language that help you from reinventing the pattern wheel?

For example, I had seen the singleton pattern quite frequently in a codebase I worked on, with the label leaking into the class name. But why is it that you have to write:

    public class DatabaseConnectionSingleton { ... }
and then deal with all the static stuff (i.e. x.Instance()) rather than

    public singleton DatabaseConnection { ... }
Like this, you could easliy use standard stuff:

    new DatabaseConnection()
and the runtime would simply return the same instance. This would keep people from reinventing the mechanism. Like IoC / DI built into your language...

[1] http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui...

May 16, 2014 · btrombley on TDD your API
What I really like about the author's approach is that it really answers the first question: "How can we validate that our API is working as intended?"

Writing your tests from the client's perspective actually gives you that certainty. TDD is a powerful tool, but in my experience its evangelists get into overly academic debates about exactly what a "unit" is and how strictly you should adhere to the red-green-refactor steps.

For a really thoughtful and in-depth approach to API TDD I recommend Growing Object-Oriented Software, Guided by Tests by Steve Freeman (http://www.amazon.com/Growing-Object-Oriented-Software-Guide...).

Well, one thing I learned from all this recent TDD related discussion is that almost nobody is aware of this book [1] and the entire school of TDD it spawned.

[1] http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

henrik_w
An alternative way of using unit tests is this: Selective Unit Testing – Costs and Benefits http://blog.stevensanderson.com/2009/11/04/selective-unit-te...

The main idea there is to unit test logic, but not unit test "coordination-code".

gary_bernhardt
That sounds vaguely similar to "Functional Core, Imperative Shell". I merge state management and coordination (together, the shell) so that the logic (the core) can be composed of pure functions without coordination overhead. So far I've done very little testing of the imperative shell.
platz
This is a great book. Although I must admit it kind of "washed over me" a bit too much. Perhaps it was just the java.. I think I need to re-read it to be able to synthesize the ideas in it, and connect the high-level ideas to the examples later in the book enough to be able to get the same results in my own work.
As a start, I recommend reading "Growing Object-Oriented Software, Guided by Tests". I am still not a 100% convert but I did get many of the same questions answered.

http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

jgon
Can you believe that I literally bought that book yesterday? I guess I have even more motivation to read through it now!
short version "programmers can mess up unit tests"

let me suggest: http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

Feb 28, 2014 · davidjnelson on Testing at Airbnb
Growing Object Oriented Software Guided By Tests is a great book on the topic: http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

Misko Hevery's (also happens to be creator of angularjs!) Testability Explorer blog is also a great resource: http://misko.hevery.com/category/testability-explorer/

I love the idea of Coinpunk.

And I wish I could contribute, but I'm so jaded and scarred by Javascript at this point it's not even funny. (For context, I spent a lot of time debugging JS on Internet Exploiter in the early 2000's long before anything cool and JS-related existed, and I do Ruby now.)

Can you do me a huge favor, though (and I'd be happy to toss you an entire bitcoin if you simply promise to do this): You NEED a better test suite. You're writing software that deals with money (or "a money," whatever), it absolutely needs a robust test suite. Primarily unit tests, but also a few functional tests. For both the server-side AND client-side code. Bitcoin itself has a reasonably good test suite, yours should too. I REALLY doubt Blockchain.info has a good one. You could distinguish yourself this way while also covering your own ass in the event you need to refactor things without breaking things :)

I didn't think tests were fun to write until I realized how much time they were saving me in debugging and headaches after the fact. Do it now, before your code size gets much bigger.

I highly recommend this book http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

Again, happy to order it for you (it's not cheap) or just toss in some more BTC if you promise to order it and read it.

I don't know what cred I can give you other than to tell you I'm "GSpotAssassin", a well-known big tipper on /r/bitcoin. (I got into bitcoin very early, and I'm an open-source developer.)

Anyway, congrats on your self-funded expedition, that is pretty fucking rad and I expect big things. :)

kyledrake
Thank you for the feedback! I agree, improving the testing suite is definitely a high priority and high on my list.
Sep 26, 2013 · myoffe on Testing code is simple
Nope, there's no way around it. Tests are not easy. But! Writing tests, learning from that, then improving your tests, which in turn help you design better software will make writing tests easier. And will help you write better code, in general.

Also, 99% of the time, the first test you are going to write in a job is for an existing piece of software. So it will definitely not be easy. But you will learn so much more about the software you are writing the test against rather than writing code in the edit-and-pray methodology.

I highly recommend reading http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

HN Books is an independent project and is not operated by Y Combinator or Amazon.com.
~ yaj@
;laksdfhjdhksalkfj more things
yahnd.com ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.