SCJP 5 | SCWCD 5
[How to ask questions] [Twitter]
Vijitha Kumara wrote:Not sure what you mean by moving Classes in to different directories, but you shouldn't make methods private/public just because you need to run tests.
And one approach to manage your tests would be put the test Classes in a similar package as with the source but under the test directory.
Vijitha Kumara wrote:And one approach to manage your tests would be put the test Classes in a similar package as with the source but under the test directory.
Sam Parson wrote:Hmm, I thought package == directory?
Ron McLeod wrote:
Vijitha Kumara wrote:And one approach to manage your tests would be put the test Classes in a similar package as with the source but under the test directory.
Sam Parson wrote:Hmm, I thought package == directory?
What Vijitha is saying is to put the application code and the test code in the same package; then you can take advantage of package-private access to peek inside or mock settings with the class under test.
Here's an example - MyApp and MyAppTest have the same package (com.example), but different directories:
.
└── src
├── main
│ └── java
│ └── com
│ └── example
│ └── MyApp.class
└── test
└── java
└── com
└── example
└── MyAppTest.class
Sam Parson wrote:
Ron McLeod wrote:
Vijitha Kumara wrote:And one approach to manage your tests would be put the test Classes in a similar package as with the source but under the test directory.
Sam Parson wrote:Hmm, I thought package == directory?
What Vijitha is saying is to put the application code and the test code in the same package; then you can take advantage of package-private access to peek inside or mock settings with the class under test.
Here's an example - MyApp and MyAppTest have the same package (com.example), but different directories:
.
└── src
├── main
│ └── java
│ └── com
│ └── example
│ └── MyApp.class
└── test
└── java
└── com
└── example
└── MyAppTest.class
Below is the problem I face when doing this...
Ron McLeod wrote:If you are going to use the structure in the example, you will need to configure your IDE with two java source locations: src/main/java, and src/test/java.
For example - with Eclipse, it would look something like this:
SCJP 5 | SCWCD 5
[How to ask questions] [Twitter]
Sam Parson wrote:However it looks like I won't be able to directly test private methods. I can only write a testcase using a protected method that calls that private method in the same class.
Paul Clapham wrote:
Sam Parson wrote:However it looks like I won't be able to directly test private methods. I can only write a testcase using a protected method that calls that private method in the same class.
There's a lot of people who would say you shouldn't need to test private methods anyway. You ought only to be testing methods which are exposed to the world, i.e. methods which are part of the class's documented API. Private methods are just implementation details, and testing shouldn't be concerned with implementation details.
Of course like anything else there are people who wouldn't agree with that. I'm not going to argue with them either, but I would still suggest that if you want to test private methods it may be that you're looking at the code too much and not looking at the documentation enough. In other words, there should documentation for the class which says "If you call this method in such a way then these things should happen and the returned value should be such and such". The documentation shouldn't mention private methods -- look at the documentation for the standard Java API and you'll see it doesn't.
Paul Clapham wrote:Well, let's put it this way: if that method returned 12, would it have a noticeable effect on the output of one of the public methods? If so, then you could consider testing for the absence of that effect.
Or let's put it another way: if that code wasn't in a method, but it was inline where line 11 is now, would you be asking how to test a section of code inside a public method?
Sam Parson wrote:To answer the first question It would give a runtime index out of bounds error ...
Sam Parson wrote:My mentor/friend was saying this would be more for QA testing and not actual unit testing or tdd. He said unit testing and tdd is running tests just to make sure it works. But running tests outside the boundary scope is more the job of QA testers who should try and break your program. I'd like to think I can automate this somehow, but if pressured for time, managing test methods at the end of every class before deployment would probably cause a headache, and I would leave it to the QA people.
Sam Parson wrote:...and not actual unit testing or tdd. He said unit testing and tdd is running tests just to make sure it works.
Paul Clapham wrote:
Sam Parson wrote:To answer the first question It would give a runtime index out of bounds error ...
Which would then percolate up until it reached a public method, which you would be testing, and which one of your test cases would catch it. But I see something about random numbers there, so conceivably it would be an error which couldn't be reproduced reliably. That's a whole separate can of worms for testing, though.
Junilu Lacar wrote:
Sam Parson wrote:My mentor/friend was saying this would be more for QA testing and not actual unit testing or tdd. He said unit testing and tdd is running tests just to make sure it works. But running tests outside the boundary scope is more the job of QA testers who should try and break your program. I'd like to think I can automate this somehow, but if pressured for time, managing test methods at the end of every class before deployment would probably cause a headache, and I would leave it to the QA people.
This is a bit odd. If you are doing TDD, leaving boundary conditions to someone else seems like a cop out. Leaving boundary conditions to QA folks is a very traditional style development attitude. Look up CORRECT testing of boundary conditions.
QA folks should really spend more of their time doing exploratory testing
Junilu Lacar wrote:
Sam Parson wrote:...and not actual unit testing or tdd. He said unit testing and tdd is running tests just to make sure it works.
This is an incomplete understanding of TDD as it relates to unit testing. TDD is a design technique, not a testing technique. It uses tests to drive how you think about design and refactoring helps you get to better designs when the tests show you something that isn't quite right. When properly done, unit tests show you examples of how your class is used and interacts with other classes to get a job done. All this is squarely in the domain of responsibility of the developer. Modern agile teams work together with "QA" or test-focused engineers. There should be no "trying to break your code" kind of attitudes but rather something more like "let's see what else we might have missed" type relationships on good teams.
Sam Parson wrote:
Also, another good video talking about what is actually happening now between devs and QA -> https://www.youtube.com/watch?v=p0O1VVqRSK0 (begin at 32:40 on his talk about the relationship between devs and QA).
OP wrote:what is actually happening now between devs and QA
Sam Parson wrote:
So this is where he and I had a bit of a disagreement on. He said I should test the min, max, and middle... For example:
In a range of integers 1 through 10...
His tests would be -> test 1, test 5, and test 10.
My tests would be -> test -2147483648, test -2147483647, test -1, test 0, test 1, test 2, test 5, test 9, test 10, test 11, test 12, test 2147483646, and test 2147483647
...
Now should I be expected to write tests for every number available outside the boundaries? What if number 1715385483 fails? How would I know it would be a test that fails without writing a test for every single number outside the boundary (also imagine how long these tests would take to execute all at once)? This is something I would hope QA would catch before release to customers.
Sam Parson wrote:Now should I be expected to write tests for every number available outside the boundaries? What if number 1715385483 fails?
Sam Parson wrote: ...develop good test habits for myself, so when my name is on the code I put out, it will not be something I would be ashamed of.
Junilu Lacar wrote:So, when you ask "should I write tests for every single number outside the boundary?" you're either being snide or you don't fully understand what the code is doing and what its limitations are, or a combination of both.
Consider Paul's rocket mass heater. |