tdd

问题 For unit tests should you; Write a test. Write code to pass it. Refactor. Or Write all your known tests. Make one pass. Refactor. I ask this because TDD states you stop writing code after all tests pass but this point is unclear. Edit One thing I think TDD focuses on more for this "rule" is in relation to stories/tasks no? Does anyone agree? A few months later A routine I've gotten into after seeing a screencast (I'll try and find the link) on the subject is as follows. Write the names of the

问题 How much should each of my unit tests examine? For instance I have this test [TestMethod] public void IndexReturnsAView() { IActivityRepository repository = GetPopulatedRepository(); ActivityController activityController = GetActivityController(repository); ActionResult result = activityController.Index(); Assert.IsInstanceOfType(result, typeof(ViewResult)); } and also [TestMethod] public void IndexReturnsAViewWithAListOfActivitiesInModelData() { IActivityRepository repository =

问题 I have a feature "Importing articles from external website". In my first scenario I test importing a list of links from the external website. Feature: Importing articles from external website Scenario: Searching articles on example.com and return the links Given there is an Importer And its URL is "http://example.com" When we search for "demo" Then the Importer should return 25 links And one of the links should be "http://example.com/demo.html" In my steps I have the 25 links in a @result

问题 I'm taking a stab at setting up unit tests for some utility classes in a project I'm working on, and one of the classes (contains licensing info) has a method that does some determination based on the current time. i.e. the license contains an expiry date, and the license string validates that date, but the actual logic to see if the license is expired is based on the current time. public boolean isValid() { return isLicenseStringValid() && !isExpired(); } public boolean isExpired() { Date

问题 I couldn't find a way to do this, though this can be done by hand so why not with moq? 回答1: Given this class public abstract class MyAbstraction { public virtual string Foo { get { return "foo"; } } } you can set up Foo (a read-only property) like this: var stub = new Mock<MyAbstraction>(); stub.SetupGet(x => x.Foo).Returns("bar"); stub.Object.Foo will now return "bar" instead of "foo". 来源： https://stackoverflow.com/questions/1454186/mocking-virtual-readonly-properties-with-moq

问题 I have a class, that subscribes to an event via PRISMs event aggregator. As it is somewhat hard to mock the event aggregator as noted here, I just instantiate a real one and pass it to the system under test. In my test I then publish the event via that aggregator and then check how my system under test reacts to it. Since the event will be raised by a FileSystemWatcher during production, I want to make use of the automatic dispatch by subscribing on the UIThread, so I can update my UI once

问题 I am wondering should I write unit test for everything. There are some classes is very difficult to write unit test. For example, I am writing some program for handling audio. The class for capturing audio from microphone, and class for play audio to speaker, how can I write unit test for those classes? I can't get output and input of those classes, so it is almost impossible to test them? The only test I can do is for getter and setter, those boring test. So the question is, what is the

问题 I am trying to use Test Driven Development to implement my signal processing library. But I have a little doubt: Assume I am trying to implement a sine method (I'm not): Write the test (pseudo-code) assertEqual(0, sine(0)) Write the first implementation function sine(radians) return 0 Second test assertEqual(1, sine(pi)) At this point, should I: implement a smart code that will work for pi and other values, or implement the dumbest code that will work only for 0 and pi? If you choose the

问题 I use NMock2, and I've drafted the following NMock classes to represent some common mock framework concepts: Expect : this specifies what a mocked method should return and says that the call must occur or the test fails (when accompanied by a call to VerifyAllExpectationsHaveBeenMet() ). Stub : this specifies what a mocked method should return but cannot cause a test to fail. So which should I do when? 回答1: A lot of mocking frameworks are bringing the concepts of mocks & stubs closer & closer

问题 I've only done minor unit testing at various points in my career. Whenever I start diving into it again, it always troubles me how to prove that my tests are correct. How can I tell that there isn't a bug in my unit test? Usually I end up running the app, proving it works, then using the unit test as a sort of regression test. What is the recommended approach and/or what is the approach you take to this problem? Edit: I also realize that you could write small, granular unit tests that would