-3

I am new to TDD and I am confused!

My first question is how would a test lead to declaration of variables with a name that you want?

For instance if I had some code in my test say

public class someTest {
    @Test
    public void test(){
        new someMethod(1,0);
    }
}

So, is there a way to name the variables in the test?

My second question is if I wanted the method to do a System.out.print("Some error") because of one of the variables value and then return what would the test need to contain?

I am completely lost. So any help is appreciated.

dimma415
  • 3
  • 1
  • 6
  • lol yeah quite a bit. Any suggestions for good tutorials online? – dimma415 Oct 28 '14 at 22:18
  • 1
    I don't think your question is very well worded. I've read it twice and I don't understand what you are asking. You can name variables anything you want...so your first question doesn't make sense. And for your second question, google is pretty good at doing that: http://stackoverflow.com/questions/1119385/junit-test-for-system-out-println – searchengine27 Oct 28 '14 at 22:20
  • See my answer. I think that'll be enough. – duffymo Oct 28 '14 at 22:27

2 Answers2

2

Forget about TDD for a moment. How would you think about testing if you started with an interface or class first? Here's what I'd do: Start with my class Foo.

public class Foo {
    private String message;

    public Foo(String m) { this.message = m; }
    public String getMessage() { return this.message; }
    public static int add(int x, int y) { return x*y; }
}

Then I'd write a JUnit test for it:

public class FooTest {
    @Test
    public void testConstructor() { 
        String expected = "Hello";
        Foo f = new Foo(expected);
        Assert.assertEquals(expected, f.getMessage());
    }

    @Test
    public void testAdd() {
        int expected = 5;
        Assert.assertEquals(expected, Foo.add(2, 3));
    }
}

I'd run this test and immediately figure out that I had a problem with that add implementation.

So what does TDD do? They take things to the extreme: write the test first, then write the class. You try to compile the test and it fails because you didn't write the class. Once you have a class implementation, you maintain a tight loop of code-test for every method, maintaining 100% passing and good coverage including happy path, error conditions, and edge cases.

TDD doesn't mean you have no idea about the class you're going to write and test. You should have some idea of the API you need before you start.

Personally, I think demanding that you write the test before the class is silly. Sketch out the class, just don't go too far before you test it. Write a method, test it, write another.

By the way: If you write a JUnit test without an Assert in it you're doing it wrong. Don't write to System.out. The pass or fail judgment should not depend on your visual inspection; it should be asserted and determined automatically.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • Apologies if I am coming across as obtuse in my questions. I am doing coursework and want to understand how this works without being spoonfed code. Thanks for the answers they are helping me get a grasp on this. I'll come back with some code in a bit and hopefully you kind souls can tell me if I am pointing in the right direction or not. – dimma415 Oct 28 '14 at 22:35
  • @dimma415 in case you have more questions, please post them in other questions. – Luiggi Mendoza Oct 28 '14 at 22:37
0

You shouldn't care about particular variables being created. If the tests you write correctly describe the behaviour you desire, and your implementation works as you want it, why do you care what variables does it have inside? Eventually, you will be forced to create some variables to satisfy one of subsequent tests. Its name shouldn't be tested - this is implementation detail, on which tests shouldn't rely.

BartoszKP
  • 34,786
  • 15
  • 102
  • 130