Hi David, On 11/11/2014 07:01 AM, dpalao.pyt...@gmail.com wrote: > I see your point. You might be right, but it is not clear to me how to > do it and if it would work: I have already tried to subclass > DiscoverRunner to modify its behaviour with little success.
If there are specific aspects of "how to do it" that are confusing to you, I could try to clarify. Or if you try it and have specific problems. > Another problem that I see: it is not an homogenous approach. I mean, > the models are created from the production database. Now I create an > independent database for testing. Of course, you will tell me that I > have to follow the TDD approach to the end: for the code that creates > the testing database too! And I would agree. But it is clearly a bit too > complicated. I'm afraid I am quite confused by this paragraph. I don't know what you mean by "not an homogenous approach". And I don't know what you mean by "the models are created from the production database." And I don't know what you mean by "an independent database for testing." Django already creates a new database for each test run. I'm not suggesting creating any additional database beyond that, just running some SQL to create your legacy (un-managed) tables in the testing database. The code that creates the testing database will be exercised at the start of every test run, and if it's not working your tests will fail because the legacy tables are not created. Personally, I'd consider that adequate; I wouldn't write any additional tests for that code. > I'm having serious doubts on how friendly Django-1.7 is with respect to > TDD... That seems an unfair conclusion, since your problems here mostly arise from using legacy tables un-managed by Django. That's not the typical situation for a Django project, and it's naturally one that will require some manual work on your part for the corresponding testing setup. Carl
signature.asc
Description: OpenPGP digital signature
