Comments on: Writing Efficient Tests

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.

By: Thomas R.

Thomas R. — Thu, 11 Mar 2010 18:24:06 +0000

Very nice post !

One important thing, when dealing with multi process tests, is that you might conflicts between concurrent process. So if you tests generate or use temporary files you need to make sure the configuration/log/temp folders are unique per process.