I am new to eclipse. I am using JUnit 4. and i have written a set up method in my class which extends Testcase where some initialization happens. I have some set of testcases in the same class. I have test data in zipped form and attached to work space.
Currently i am able to run all test cases for a single test data. Somehow i want the control to go back to set up() to take second test data and run all the test cases.
Is it possible? ans if yes can anyone please send some code snippet?
Thanks in advance
Thanks for the reply but where should i keep such code whether it should be kept in set up method and how test data will be taken up from set up?
You need to use the Parameterized runner. It allows you to run the same test with multiple test data. e.g. The following will imply that the tests will run four times, with the parameter "number" changed each time to the value in the array.
#RunWith(value = Parameterized.class)
public class StackTest {
Stack<Integer> stack;
private int number;
public StackTest(int number) {
this.number = number;
}
#Parameters
public static Collection data() {
Object[][] data = new Object[][] { { 1 }, { 2 }, { 3 }, { 4 } };
return Arrays.asList(data);
}
...
}
Edit
Not sure what isn't clear, but I'll attempt to clarify.
The #RunWith(value = Parameterized.class) annotation is required. You must have a method annotated with #Parameters that returns a Collection object, each element of which must be an Array of the various parameters used for the test. You must have a public constructor that will accept these parameters.
Additional information, and another example can be found in the documentation.
Even more examples.
Related
In my test the next flow takes place:
I do some actions (for example buy a product) before all tests are run
Then in each test I check one assertion
I use NUnit framework to run test so I use [TestFixtureSetUp] to mark a set of actions that are done once before all tests. Then I use [Test] or [TestCase()] to run tests.
Often it happens that I need to check the same things but perform different flow. So I have to parameterize [TestFixtureSetUp]. Can I somehow do it?
So I want to make my set of actions that is performed once before all tests depended on parameters.
If it's possible to do with different frameworks or different flow structure please tell me)
Example of my code:
[TestFixtureSetUp] //This will be done once before all tests
public void Buy_Regular_One_Draw_Ticket(WayToPay merchant)
{
//here I want to do some actions and use different merchants to pay.
//So how can I send different parameters to this method?
}
Guys the solution is the next: constructor of the class runs before [TestFixtureSetUp] so all actions that were made in [TestFixtureSetUp] now are made in the constructor of a class.
And we have an ability to send parameters to the constructor! For this we use [TestFixture()].
The whole code is the next:
[TestFixture(WaysToPay.Offline)]
[TestFixture(WaysToPay.Neteller)]
public class DepositTests
{
//Constructor takes parameters from TestFixture
public DepositTests(WaysToPay merchant)
{
//Do actions before tests considering your parameters
}
[Test]
public void Your_test_method()
{
//do your verification here
}
}
Using this approach instead of using [TestFixtureSetUp] you can make your tests more flexible. So the behavior is the same as if [TestFixtureSetUp] can get parameters.
Should unit tests test all passing conditions as well as all failing conditions?
For example, imagine I have a test Widget_CannotActiveWidgetIfStateIsCancelled.
And let's say there are 100 possible states.
Can I get away with testing only that I cannot activate my widget when State == Cancelled, or do I have to also test that I CAN activate it in each of the other 99 states?
Is there some compromise that can let me avoid spending all my time writing tests? :)
It seems you are asking whether your tests should be exhaustive: whether you should test for all possible states. The answer is a resounding no, for the simple reason that even simple code can have far too many states. Even small programs can have more potential states than can be tested even if you used all the time there has been since the big bang.
You should instead use equivalence partitioning: identify groups of states, such that all the states in a group are likely to have similar behaviour, then have one test case per group.
If you do that, you might discover you need only two test cases.
This is a scenario where you want to use one parametrized test which gets all 99 values as input.
Using xUnit.net, this could look like this (untested, might contain small compilation errors):
[Fact]
public void Widget_CannotActiveWidgetIfStateIsCancelled()
{
// Arrange ...
sut.State = State.Cancelled;
Assert.False(sut.CanActivate);
}
[Theory, ValidStatesData]
public void Widget_CanActivateWidgetIfStateIsNotCancelled(State state)
{
// Arrange ...
sut.State = state;
Assert.True(sut.CanActivate);
}
private class ValidStatesDataAttribute : DataAttribute
{
public override IEnumerable<object[]> GetData(
MethodInfo methodUnderTest, Type[] parameterTypes)
{
return Enum.GetValues(typeof(State))
.Cast<State>()
.Except(new [] { State.Cancelled })
.Select(x => new object[] { x });
}
}
If you're using NUnit you can use attributes so you only have to code one test but can test all 100 values.
I have an ASP.NET page that is the base to many more derived pages and it contains the following protected method
protected Change SetupApproval(string changeDescription)
{
Change change = Change.GetInstance();
change.Description = changeDescription;
change.DateOfChange = DateTime.Now;
change.MadeBy = Common.ActiveDirectory.GetUsersFullName(AccessCheck.CurrentUser());
change.Page = PageName;
return change;
}
I want to write the following Unit test
[TestMethod]
public void SetupApproval_SubmitChange_ValidateDescription()
{
var page = new DerivedFromBaseClass();
var messageToTest = "This is a test description";
var change = (page as InternalAppsPage).SetupApproval(messageToTest);
Assert.IsTrue(messageToTest == change.Description);
}
I'm sure there's a lot wrong with this code (so feel free to suggest corrections), but my main goal is to start implementing some tests for this entire project. I decided to start small - one method at a time. I first tried creating a new Test Project, but then I can't access the SetupApproval method because it is protected. My next attempt was to put the TestMethod inside of the base page, but then there's no way to Run Tests.
Lastly, I'm using Visual Studio 2008's default test framework.
Two options:
Assuming DerivedFromBaseClass is a class which solely exists for testing, just give it a new public (or internal) method which just calls SetupApproval and returns the return value.
Make the method protected internal instead, and make sure you have InternalsVisibleTo set up for your test assembly so it has access to internal methods. Document that this is for the sake of testing.
The first option is cleaner, the second is simpler, particularly if you have a lot of protected methods and the base class is non-abstract.
A second MSpec question from me in a day, this is a new record. I'm trying to get smart on MSpec very quickly and I've run into some old problems I've always had with MSpec.
Scenario: I have a repository that contains a bunch of cartoons. Right now I only need to filter this set on a single Name parameter, which is a string. As I'm told I'll need to filter this on more properties later on, I decide to create a class which takes in my ICartoonRepository via IoC, and contains a simple method that's called GetByName(string name).
You might argue this is overkill, but I'm trying to teach myself how to use MSpec and work in a more TDD manner.
So I create the following:
[Subject(typeof(CartoonViewModelBuilder))]
public class when_cartoon_repository_is_asked_to_get_by_id : specification_for_cartoon_viewmodel_builder
{
static string name;
static Cartoon the_cartoon;
static Cartoon result;
Establish context = () =>
{
name = "Taz";
the_cartoon = new Cartoon();
the_cartoon_repository.Stub(r => r.GetAll().Where(x=>x.Name == name).FirstOrDefault()).Return(the_cartoon);
};
Because of = () => result = subject.GetByName(name);
It should_return_cartoon = () => result.ShouldBeTheSameAs(the_cartoon);
}
This fails on the stub as the repository is empty. I have a couple other tests that pass fine (simply testing the GetAll(), etc). Do I need to add things to the repository to test it? This is where I'm stumped, please be gentle.
Also, if I'm writing the linq statement in the stub, it seems like I'm doing it twice, in the actual implementation and in the test. Is this the point? It doesn't feel right. Is there a better way I can write this test?
For clarity sake, here is the actual implementation (I'm omitting the interface and the class, which just has one property:
public class CartoonViewModelBuilder: ICartoonViewModelBuilder
{
readonly ICartoonRepository _cartoonRepository;
public CartoonQueryObject(ICartoonRepository cartoonRepository)
{
_cartoonRepository = cartoonRepository;
}
public IList<Cartoon> GetAllCartoons()
{
return _cartoonRepository.GetAll();
}
public Cartoon GetByName(string name)
{
return _cartoonRepository.GetAll().Where(x => x.Name == name).FirstOrDefault();
}
}
Edit 1: Based on the lack of responses, I should say that if I were using something like NUnit, I would be creating a method on the testing class that was like, "LoadDummyData" and threw data into the repository, then I'd do complex filtering or view model building and sort of manually checked what happened. This made large refactoring a chore. It seems like specs allows you to avoid that?
Edit 2: Here's my corrected test which now passes. Let me know if I'm doing it right, I think I am. Thanks again for the hand holding!
static string name;
static Cartoon the_cartoon;
static Cartoon result;
static IQueryable<Cartoon> the_cartoons;
Establish context = () =>
{
name = "Taz";
the_cartoon = new Cartoon {Name = name};
the_cartoons = new List<Cartoon> {the_cartoon, new Cartoon(), new Cartoon() }.AsQueryable();
the_cartoon_repository.Stub(r => r.GetAll()).Return(the_cartoons.ToList());
};
Because of = () => result = subject.GetByName(name);
It should_return_cartoon = () => result.ShouldBeTheSameAs(the_cartoon);
Edit 3: Gave you both points, but I can only award one best answer unfortunately.
The actual reason of this test failing is the way you're mocking your repository. I would be very surprised if method chains like r.GetAll().Where(x=>x.Name == name).FirstOrDefault() could be mocked so easily, as it uses LINQ extension methods and lambda clauses. The framework should really throw NotSupported exception or something to let you know that you can't mock LINQ queries as a whole.
To mock LINQ query result, you should provide properly prepared underlying data collection, which is the starting point of LINQ query. In your example you should mock just r.GetAll() to return a collection containing your element with proper name. The actual query will run on your "mocked" data and retrieve the object you expect.
This removes the need to duplicate your LINQ query in code and in test, what is strange, as you noted.
EDIT: Code in your edit is like I've suggested, technically OK.
Anyway, by now it's a bit overkill, as you've said. Your class under test doesn't do anything beside the call to the mocked repository, so the value of that test is rather small. But it may be a good start if you're going to have some more logic in GetByName method.
If you want to test your repository implementation, don't stub it! MSpec or not, I would add a list of known items to the repository and then issue the query with GetByName. Then assert that just the item you expect was returned. I would also use ShouldEqual as the repository might work with the items you add and return a different instance, though considered equal (aggregate IDs are equal).
I am interested in the best way to write unit tests for a class whose public API involves some kind of a flow, for example:
public class PaginatedWriter {
public void AppendLine(string line) { ... }
public IEnumerable<string> GetPages() { ... }
public int LinesPerPage { get; private set; }
}
This class paginates text lines into the given number of lines per page. In order to test this class, we may have something like:
public void AppendLine_EmptyLine_AddsEmptyLine() { ... }
public void AppendLine_NonemptyLine_AddsLine() { ... }
public void GetPages_ReturnsPages() {
writer.AppendLine("abc");
writer.AppendLine("def");
var output = writer.GetPages();
...
}
Now, my question is: is it OK to make calls to AppendLine() in the last test method, even though we are testing the GetPages() method?
I know one solution in such situations is to make AppendLine() virtual and override it but the problem is that AppendLine() manipulates internal state which I don't think should be the business of the unit test.
The way I see it is that tests usually follow a pattern like 'setup - operate - check - teardown'.
I concentrate most of the common setup and teardown in the respective functions.
But for test specific setup and teardown it is part of the test method.
I see nothing wrong with preparing the state of the Object Under Test using method calls of that object. In OOP I would not try to decouple the state from the operations since the paradigm goes to great lengths to unify them and if possible even hide the state. In my view the unit under test is the Class - state and methods.
I do make visual distinction in the code by separating the setup block from the operate block and the verify block with an empty line.
Yes, I'd say that's absolutely fine.
Test in whatever way you find practical. I find there's rather too much dogma around testing exactly one thing in each test method. That's a lovely ideal, but sometimes it's just not nearly as practical as slightly less pure alternatives.