tdd

Just when I'd achieved an effective development and build environment with the android-maven-plugin , the new kid on the block, Gradle, starts making inroads into the Android circles. Not being hot on Groovy and with the android-gradle plugin almost as fragmented as the OS itself I've hit some issues. Specifically around building library projects, with flavours and our buddy Robolectric . Short version I am at a loss as to what my next move should be upon encountering the gradle error; Cannot add a SourceSet with name 'testDebug' as a SourceSet with that name already exists. The error emanates

I am trying to use Rhino.Mocks to mock up a ControllerContext object to gain access to runtime objects like User, Request, Response, and Session in my controller unit tests. I've written the below method in an attempt to mock up a controller. private TestController CreateTestControllerAs(string userName) { var mock = MockRepository.GenerateStub<ControllerContext>(); mock.Stub(con => con.HttpContext.User.Identity.Name).Return(userName); mock.Stub(con => con.HttpContext.Request.IsAuthenticated).Return(true); var controller = CreateTestController(); // left out of example for brevity controller

I have finished Chapter 6 of railstutorial but all my User model specs have started failing soon after I added password & password_confirmation with the following errors: Failures: 1) User Failure/Error: @user = User.new(name: "Example User", email: "user@example.com", ActiveRecord::UnknownAttributeError: unknown attribute: password # ./spec/models/user_spec.rb:17:in `new' # ./spec/models/user_spec.rb:17:in `block (2 levels) in <top (required)>' 2) User Failure/Error: @user = User.new(name: "Example User", email: "user@example.com", ActiveRecord::UnknownAttributeError: unknown attribute:

In TDD(Test Driven Development) development process, how to deal with the test data? Assumption that a scenario, parse a log file to get the needed column. For a strong test, How do I prepare the test data? And is it properly for me locate such files to the test class files? Maven, for example, uses a convention for folder structures that takes care of test data: src main java <-- java source files of main application resources <-- resource files for application (logger config, etc) test java <-- test suites and classes resources <-- additional resources for testing If you use maven for

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 tests/behaviour/functionality at the top of the test class. Cut and paste the test name. Complete the

I would like to be about to use a list, array, and/or seq as a parameter to xUnit's InlineData. In C# I can do this: using Xunit; //2.1.0 namespace CsTests { public class Tests { [Theory] [InlineData(new[] {1, 2})] public void GivenCollectionItMustPassItToTest(int[] coll) { Assert.Equal(coll, coll); } } } In F# I have this: namespace XunitTests module Tests = open Xunit //2.1.0 [<Theory>] [<InlineData(8)>] [<InlineData(42)>] let ``given a value it must give it to the test`` (value : int) = Assert.Equal(value, value) [<Theory>] [<InlineData([1; 2])>] let ``given a list it should be able to pass

Next term, I'll need to write a basic operating system for Motorola 68K processor as part of a course lab material. Is there a Linux emulator of a basic hardware setup with that processor? So my partners and I can debug quicker on our computers instead of physically restarting the board and stuff. Is it possible to apply test-driven development technique to OS development? Code will be mostly assembly and C. What will be the main difficulties with trying to test-drive this? Any advice on how to do it? You certainly can tdd this project. First off decouple all accesses to the hardware with