Hacker News Reader

Comment by rmoriz | Hacker News Reader

How about BDD, test-driven development and quality insurance? Does Go provide an ecosystem that supports agile refactorings that are common in lean startups?

You can say anything bad about the performance of Ruby and Rails etc. but rspec, cucumber, capybara, vcr, factorygirl are really important features to start from zero and reach a viable product.

View on HN

> test-driven development

`go test`.

> Does Go provide an ecosystem that supports agile refactorings that are common in lean startups?

Go has a compiler and is staticly and strongly typed. Which automatically makes it at least an order of magnitude easier to refactor safely.

Not really sure about the other stuff you mentioned. I've never even heard of BDD before.

I've heard this argument before e.g. we don't need to test because the compiler catches errors. The compiler catches the mot trivial of error conditions. Unfortunately it doesn't address faulty logic/behavior.

I rather like what go has set up for test's. They made it as small and functional as they could.

Out of curiosity. How does a language specifically support "agile refactoring"? What features permit (or hinder) stopping every couple of weeks and removing the accumulated WTF's in the codebade?

Want to buy a left handed stapler?

Go's interfaces make it really, really easy to change things with very little code changing. Go's testing tools are superb.

Can you blog about it in the future? Couldn't find good resources and tools about testing in Go. Especially with concurrency this seems to be very important.

Testing: http://golang.org/doc/code.html#Testing

Iterating: http://vimeo.com/53221560

from a testing point of view this looks pretty week. I would not bet my business on something that has not a testing culture.

I wouldn't say Go doesn't have a testing culture. On what basis do you make that assertion?

I write better tests for my Go code than for any code in other languages that I write. But maybe I just think in complementary ways to Go's testing philosophy.

What? Go check out any moderately popular library in Go (including packages in the standard library), and I bet you're fairly likely to see a `*_test.go` file somewhere (perhaps more than one).

Unit testing in Go is refreshingly simple. And it comes standard with the Go toolchain.

The talk that I gave just before the one linked above talks about testing: http://vimeo.com/53221558

What makes you say it doesn't have a testing culture? I think you're just trying to justify not using Go and sticking to your choice.

I haven't came across any Go libraries without tests.

* as far as I can see very few go projects use CI (e.g. travis)

* gospec seems to be dead/not widely used

* I don't see projects measuring their code coverage

* As pointed out in my first comment, I couldn't find high level testing tools and none of the repliers could name one, too.

If you don't have tests to measure function and performance, any new technology is just playing another round of Roulette and/or "bike-shedding". Most projects and companies — to my knowledge — don't fail because of 30 servers for Rails but in the inability to iterate (to find a profitable business segment) without investing/burning bulkloads of money re-engineering. Therefore any serious business use requires a deep evaluation and comparision with existing methods, especially in the quality of service sector.

The Agile/XP/TDD/BDD-movement was not created because of "bad and slow" programming languages. It's because failure happens all the time if you like or not. It's about dealing with the omnipresent risc and changing specs.

Agreed, but something you also have to worry about is your stack becoming unmaintainable. Sometimes it's worth re-engineering your stack. For instance, even the simplest programs have a "time until too complex to safely be maintained".

I suppose you have to make that time far enough away that it won't affect your business. If you go past it, your good developers will leave and you'll likely only get lower class devleopers who have to take the job.

As a result your entire stack will suffer. The business side is important, but the entire engineering side can die if you neglect it too much.

Complexity must be managed.

That said, you are correct about:

* Few projects use CI. I think this is due to the fact that most of the libraries being developed are done by very small teams that see it as too much overhead.

* Same with code coverage.

* Most find the testing that Go uses for the language itself to be more than enough.

I think that Go has a much different attitude towards development than you are used to.

I can't quite quantify why and I could be wrong, but I suspect not all of the testing methodologies you talk about are necessary.

Would be great for someone else also experienced with Go and experience with the type of testing environments rmoriz describes to chime in!

Hmm I see a lot of opportunity

Go doesn't have any mocking framework like Mockito/Java or Rspec mock. You will end up writing a ton of code yourself if you want to mock something simple.

Uh what? No, that couldn't possibly be less true. Have you ever heard of "interfaces" in Go? They're kind of an important feature.

That's what the other gophers say too. Java has interfaces too, but it also has Mockito that makes testing much easier. You should look into it. Mocking library will help reduce boiler code. You would know that if you had used one.

>You would know that if you had used one.

Cute.

My bad. :)

Go interfaces are not the same as Java interfaces. Go interfaces are implemented using structural sub-typing.

I've only dabbled a bit but I haven't seen a DSL that easily creates a mock that implements all the methods of a given interface, verifies that methods were (not) called with expected arguments, and returns or throws canned values. It's not difficult to write mocks from scratch, but it's very repetitive and hard to skim what the test does.

You nailed it!

https://code.google.com/p/gomock/ works well.

Reply on news.ycombinator.com