tdd

I'm currently in the process of testing our solution that has the whole "gamut" of layers: UI, Middle, and the omnipresent Database. Before my arrival on my current team, query testing was done by the testers manually crafting queries that would theoretically return a result set that the stored procedure should return based on various relevancy rules, sorting, what have you. This had the side effect of bugs being filed against the tester's query more often than against the actual query in question. I proposed actually working with a known result set that you could just infer how it should

I've been pushing my Google Fu to the limits trying to find the most recommended / stable setup for doing TDD + CI for Windows Phone applications. Can anyone who has successfully been doing this point me in the right direction? Here's what I want to be able to do (if it's possible): Write unit tests for view models and application services that don't require phone functionality Execute tests directly in Visual Studio via Resharper or TD.NET Execute the unit tests from the command line with XML out, without launching the emulator Preferably be resiliant (as far as third party libraries go) to

I'm working on a project which is in serious need of some performance tuning. How do I write a test that fails if my optimizations do not in improve the speed of the program? To elaborate a bit: The problem is not discovering which parts to optimize. I can use various profiling and benchmarking tools for that. The problem is using automated tests to document that a specific optimization did indeed have the intended effect. It would also be highly desirable if I could use the test suite to discover possible performance regressions later on. I suppose I could just run my profiling tools to get

I am trying to learn TDD and unit testing concepts and I have seen the mantra: "red, green, refactor." I am curious about why should you refactor your code after the tests pass? This makes no sense to me, because if the tests pass, then why are you messing with the code? I also see TDD mantras like "only write enough code to make the test pass." The only reason I could come up with, is if to make the test pass with green, you just sloppily write any old code. You just hack together a solution to get a passing test. Then obviously the code is a mess, so you can clean it up. EDIT: I found this

I'm participating in a project using ASP.NET MVC 3 and DataAnnotations. We have DataAnnotations in ViewModels classes. How do you write unit tests for these validations? ViewModel example: public class AchievementVM { [Required(ErrorMessage = "The title field is required.")] [StringLength(100, ErrorMessage = "Title must be 100 characters or less.")] public string Title { get; set; } } Thanks! Phil Patterson The .NET framework comes with a Validator class which can exercise your validation logic in isolation. The code to test could look like this: var achievement = new AchievementVM(); var

So I'm starting to catch the TDD bug but I'm wondering if I'm really doing it right... I seem to be writing A LOT of tests. The more tests the better, sure, but I've got a feeling that I'm over doing it. And to be honest, I don't know how long I can keep up writing these simple repetitive tests. For instance, these are the LogOn actions from my AccountController: public ActionResult LogOn(string returnUrl) { if (string.IsNullOrEmpty(returnUrl)) returnUrl = "/"; var viewModel = new LogOnForm() { ReturnUrl = returnUrl }; return View("LogOn", viewModel); } [AcceptVerbs(HttpVerbs.Post)] public

So regards logging from SO and other sites on the Internet the best response seems to be: void DoSomething() { Logger.Log("Doing something!"); // Code... } Now generally you'd avoid static methods but in the case of logging (a special case) this is the easiest and cleaniest route. Within the static class you can easily inject an instance via a config file/framework to give you the same effect as DI. My problem comes from a unit testing perspective. In the example code above imagine the point of DoSomething() was to add two numbers together. I'd write my unit tests for this fine. What about the

Since Class based Generic Views in Django involve some work by the framework I find very hard to work with them in a TDD style. Now I use the TestClient to access the view from the http mocked stack, but I would prefer to properly unittest specific methods (es. overrides of get_object and get_queryset ) before 'functional' testing with the TestClient. Is there a ( quick ) way to obtain a proper instance of a ClassView to perform unit test on it? Generally, that would include creating a request via the RequestFactory and instantiating the view class with keyword arguments. Afterwards, you can