Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slow Tests Are the Symptom, Not the Cause

re-factor.com

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Slow Tests Are the Symptom, Not the Cause

#41

Post by tieTYT »

ExpiredLink wrote: post #28
tieTYT wrote: post #27

Earlier quoted context omitted.

Spring was probably born as a reaction to EJB. And if you've ever written tests for EJBs you're grateful to Spring for providing an alternative.

I've written UnitTests for EJBs today. No Spring bloatware needed.

Well what version of JEE are you using? Compare that to writing unit tests for the version of JEE that existed when Spring was created. A lot of what makes EJBs easier to test today is because of influence by dependency injection frameworks (like Spring) from yesterday.

Re: Slow Tests Are the Symptom, Not the Cause

#42

Post by tieTYT »

schmrz wrote: post #40
regularfry wrote: post #37

Earlier quoted context omitted.

TDD advocates would disagree.

I'm not sure I follow. What exactly would TDD advocates disagree on?

I think he is replying to this:

> ... your tests shouldn't dictate how you will design and write your application

I know that's not your whole quote and a lot of context is lost in that "...", but I think that's what he's replying to.

Re: Slow Tests Are the Symptom, Not the Cause

#43

Post by tieTYT »

regularfry wrote: post #35
lmm wrote: post #4

In my experience when you do this you end up with anaemic tests that are basically useless. As the page comes close to admitting, all you do is write the same code twice. The result is a lot of wasted effort on unit tests that never fail. In an app designed like this the integration tests are the useful ones, because they're more contentful and test assumptions that are more likely to be wrong. The article flatly ass…

I'd argue that even a test which is a copy and paste of the implementation method - literally the same code, twice - has value, because you can then refactor the implementation as much as you like in future and know that you're covered. Nothing says that because they are the same now, they will be forever.

As someone who has personal experience making this mistake, I disagree with you. You lose the most important purpose of the test: The confidence that your code works. If you write the code twice all you know is that your code hasn't changed.

And in my personal experience, you CAN'T refactor because the test is so tightly aligned with the production code. EG: moving a variable declaration up or down one will break a test even though it didn't change anything.

Re: Slow Tests Are the Symptom, Not the Cause

#44

Post by lectrick »

programminggeek wrote: post #31
lectrick wrote: post #26

Earlier quoted context omitted.

Obvious looks great. Can't wait to try it on a project actually. Do you know anyone who's used it out in the wild to build cool stuff?

Surprisingly, even though the original version was built in ruby, people are taking the structure and using it in .NET, Java, etc. A lot of things we had to build in ruby already exist as things like interfaces in other statically typed languages. In a language like Scala Obvious is literally just a way you would organize your program, not so much a library. It already has everything else you need, even things like i…

I looked at the source and saw that you basically built a way to declare a method which asserts a contract at runtime.

I like the idea of an object or collection of objects having a generic interface that can be mapped to all sorts of things such as a commandline or an HTTP POST etc... I am also at a job where we are struggling with the ol' "monolithic codebase" and we're investigating solutions such as this architecture.

Re: Slow Tests Are the Symptom, Not the Cause

#45

Post by regularfry »

tieTYT wrote: post #42
schmrz wrote: post #40

Earlier quoted context omitted.

I'm not sure I follow. What exactly would TDD advocates disagree on?

I think he is replying to this: > ... your tests shouldn't dictate how you will design and write your application I know that's not your whole quote and a lot of context is lost in that "...", but I think that's what he's replying to.

Pretty much, yes. TDD would say that if testing is painful, changing your design to take away that pain will leave you with a better design overall.

Re: Slow Tests Are the Symptom, Not the Cause

#46

Post by gingerlime »

regularfry wrote: post #38
gingerlime wrote: post #30

after reading sandi metz POODR[1], I tend to prefer the approach on the post too. However, I also must say that the time it takes to execute unit tests, even with factories, db access etc is still an order of magnitude faster than running things like feature tests with capybara. This is by far the biggest drain on test time (and resources), and these are also the tests most difficult to write and maintain. Way too of…

I think the key here is not to try to aim for anything like full coverage with capybara, just enough to be effective. Martin Fowler has some words on this here: http://martinfowler.com/bliki/TestPyramid.html

Thanks for the link. We're pretty much using this pyramid approach intuitively, but just as a single data point - one feature test takes around 15% of the execution of our entire test suite (with around 850 tests). This one test is quite comprehensive and touches the core functionality, but nevertheless suffers from all the negative aspects Martin Fowler mentions.

Were we to improve our unit tests to run even faster, as the post suggests, the difference in execution time will become much more pronounced. several orders of magnitude.

I think feature/UI testing is still an interesting space for better tools, but of course the problem is very difficult to solve.

Post reply on HN