tdd

问题 Possible Duplicate: How to generate dynamic (parametrized) unit tests in python? I have a function to test, under_test , and a set of expected input/output pairs: [ (2, 332), (234, 99213), (9, 3), # ... ] I would like each one of these input/output pairs to be tested in its own test_* method. Is that possible? This is sort of what I want, but forcing every single input/output pair into a single test: class TestPreReqs(unittest.TestCase): def setUp(self): self.expected_pairs = [(23, 55), (4,

问题 anti-pattern : there must be at least two key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or bad idea: Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results, and A refactored solution that is clearly documented, proven in actual practice and repeatable. Vote for the TDD anti-pattern that you have seen \"in the wild\" one time

问题 I have a IBankAccount interface that I will be passing to the ApplicationService. The changes made on the account objects (in the ApplicationService project) need to be persisted in the database. The repository receives the changes using IBankAccount interface. How can I persist this data into database? This is implemented using LINQ to SQL. Note: Following is a comment from Scott in http://weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-querying-our-database.aspx \"Add the

问题 In TDD development, the first thing you typically do is to create your interface and then begin writing your unit tests against that interface. As you progress through the TDD process you would end-up creating a class that implements the interface and then at some point your unit test would pass. Now my question is about the private and protected methods that I might have to write in my class in support of the methods/properties exposed by the interface: Should the private methods in the

问题 I\'m new in unit testing and I\'m trying to figure out if I should start using more of \'internal\' access modifier. I know that if we use \'internal\' and set the assembly variable \'InternalsVisibleTo\', we can test functions that we don\'t want to declare public from the testing project. This makes me think that I should just always use \'internal\' because at least each project (should?) has it\'s own testing project. Can you guys tell me a reason why I shouldn\'t do this? When should I

问题 I\'m using this tutorial to Fake my DbContext and test: http://refactorthis.wordpress.com/2011/05/31/mock-faking-dbcontext-in-entity-framework-4-1-with-a-generic-repository/ But i have to change the FakeMainModuleContext implementation to use in my Controllers: public class FakeQuestiona2011Context : IQuestiona2011Context { private IDbSet<Credencial> _credencial; private IDbSet<Perfil> _perfil; private IDbSet<Apurador> _apurador; private IDbSet<Entrevistado> _entrevistado; private IDbSet

问题 I\'m sure most of you are writing lots of automated tests and that you also have run into some common pitfalls when unit testing. My question is do you follow any rules of conduct for writing tests in order to avoid problems in the future? To be more specific: What are the properties of good unit tests or how do you write your tests? Language agnostic suggestions are encouraged. 回答1: Let me begin by plugging sources - Pragmatic Unit Testing in Java with JUnit (There's a version with C#-Nunit

问题 The thing I\'ve found about TDD is that its takes time to get your tests set up and being naturally lazy I always want to write as little code as possible. The first thing I seem do is test my constructor has set all the properties but is this overkill? My question is to what level of granularity do you write you unit tests at? ..and is there a case of testing too much? 回答1: I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level

问题 I\'m building a class library that will have some public & private methods. I want to be able to unit test the private methods (mostly while developing, but also it could be useful for future refactoring). What is the correct way to do this? 回答1: If you are using .net, you should use the InternalsVisibleToAttribute. 回答2: If you want to unit test a private method, something may be wrong. Unit tests are (generally speaking) meant to test the interface of a class, meaning its public (and

问题 How do I unit test (using xUnit) a class that has internal private methods, fields or nested classes? Or a function that is made private by having internal linkage ( static in C/C++) or is in a private (anonymous) namespace? It seems bad to change the access modifier for a method or function just to be able to run a test. 回答1: Update: Some 10 years later perhaps the best way to test a private method, or any inaccessible member, is via @Jailbreak from the Manifold framework. @Jailbreak Foo foo