Comments on: Writing Efficient Tests

By: Nicolae`

Nicolae` — Thu, 23 Feb 2012 10:44:38 +0000

Thank’you very much. That made my life easier

By: Karopapier, symfony und der ganze Rest » Blog Archive » Starting to get addicted to unit testing…

Mon, 15 Mar 2010 09:59:33 +0000

[...] paying more attention to unit testing and writing tests in my symfony apps. But not until this awesome post from Bernhard Schussek, I really understood how you can make your testing life easier and get tests done better, faster [...]

By: Romain

Romain — Fri, 12 Mar 2010 14:17:34 +0000

This is an excellent article. Developers knowing what is a unit test is rare nowadays…

By: uberVU - social comments

uberVU - social comments — Thu, 11 Mar 2010 21:53:18 +0000

Social comments and analytics for this post…

This post was mentioned on Twitter by webmozart: New blog post published. http://bit.ly/c4cxdE #efficient #testing #symfony…

By: Matthieu

Matthieu — Thu, 11 Mar 2010 21:19:35 +0000

@NiKo Apart from the initial part (Filling the database with all the test data from YAML files) that I do just once (or each time I change my fixtures), it doesn’t seem to me that using transactions is slow.
Anyway I guess it is faster than reloading the test data.

By: Christian

Christian — Thu, 11 Mar 2010 21:12:28 +0000

Very interesting article! I think I can use a lot of this even when I’m testing with PHPUnit.

But I wonder about Lime2. So far it has been mentioned that Symfony 2 is going to use PHPUnit, symfony 1.4 is not supposed to switch base technologies, Lime2 development became low priority, ..
What is the purpose and goal of Lime2? I mean I do think your ideas so far have been inspiring, but what will be the outcome?
Shouldn’t there be a Lime2 website finally?

By: NiKo

NiKo — Thu, 11 Mar 2010 20:29:50 +0000

One more very good article on this blog.

The transaction trick is a good one, but it’s still very slow – at least regarding my quick personnal testing.

The in-memory SQLite database trick is fantastic, unfortunately hardly usable as soon as you’re using RDBMS-specific features such as ones provided by MySQL or Postgresql (they’re providing so many useful ones it’d be a shame not to benefit from them… I know ORM are not intended to be used this way but the shared features accross RDBMS implementation are really thin actually.)

I think at some point System Tests will always end beeing slow, just by design: if the system to be tested is complex, related tests will test this complexity; and testing complexity naturally takes time. But of course I agree we should always try to reduce at max the amount of unnecessary executions to gain maximum efficiency, and rapid feedback to keep agility.

Personnaly, I’m a big fan of continuous integration, the tests are run periodically so I can keep concentrate on the code and I get alerts as soon as something breaks (so you need of course to commit atomically to reduce the surprise effect I didn’t find the perfect compromise yet, but will look forwards giving a try to lime2 because its mocking api is really interesting by itself

Keep up the good work!

By: Bernhard

Bernhard — Thu, 11 Mar 2010 19:07:49 +0000

@Matthieu: Sounds like a good solution, too. I probably need to experiment a little more with that approach.

By: Matthieu

Matthieu — Thu, 11 Mar 2010 19:03:24 +0000

Great post!

What do you think about transactions?

Between the execution of each function in my (Lime2) test class, a beginTransaction() and endTransaction() is called to revert the database to its previous state. This is really fast I think.

By: Bernhard

Bernhard — Thu, 11 Mar 2010 18:26:12 +0000

Thanks for the comment, Thomas. You are absolutely right. I think I will publish another post that will deal exclusively with concurrent testing.