How to unit-test an enterprise symfony project?

I´m working on a huge project at my work. We have about 200 database tables, accordingly a huge number of Models, Actions and so on.

How should I begin to write tests for this?

My biggest problem is, with symfony you can test with the lime framework, which is great. But most of the code writes, deletes or d开发者_Python百科o other things with the database. So how can I test a Model without interacting with the database?

I want to do unit-tests because I´ve had problems with bugs in my code, through the refactoring of functions but I don´t even know how to start. The examples from the documentation cover only a very small function. How does it look, when the action file is over 700 lines of code?

Great question.. I've personally run into this all over the place.

Here's what I've found so far:

1) Get a dev database.. DO NOT test on a prod database!

2) It may sound trite, but start small and simple.

3) I don't know what your field is (e-commerce database, contacts database, etc...) but say it is an e-commerce DB. Start by testing creating some order models and saving them. Maybe recreate a real order in a test harness so it saves to the DB. Now you can quickly create 1000 orders to run tests on.. WAY faster than manually doing web checkouts for things. For maximum benefit, create a model of some thing you are currently working on so you can use it during your testing.

4) Now start testing the various methods that your model provides. Again, stick to the ones that are relevant to what you are currently trying to fix/work with. Don't worry about testing everything, just test some stuff, and make sure you can repeat your tests.

5) Need to test controllers? Cool, now you have a model to work with that you don't care about messing up, becuase it isn't real... Need some variations? Create more test suites that build differnt models to fit each of your needs. Models can be complex, but you should be able to write some test functions that create variations of your various models. Then run your controllers against those...

6) Keep plucking away at code coverage.

WARNING: Be careful about being the only one running the unit tests.. You will quickly become the most effective problem solver, but people will then try to get YOU to fix everything...

700 lines in a single controller action? Testing has a way of exposing issues in your own code in other ways than the obvious assertions. If something is difficult to test for whatever reason, there is something wrong with the code.

When starting to test a project, big or small, the focus should be code coverage. Don't worry so much about edge cases at first (unless the situation calls for it). When starting to test a project I like to start with the models as they are the most straightforward. From there move on to controller testing and see how it goes.