Manual assertions are not in play. These are not in the tests. Regular
assertEquals calls are made.
Investigating the hierarchy once again to give you a reference I found one
thing that is less then optimal with them. The tests are in testclasses not
generic to the tested resources: XcpOssResource
Please mention lines in tests which is justifying your statement "They prove
that the fragile integrity of the class hierarchy that has been meddled with so
often is still intact”
I have no problem with solution. I have problem with tests.
For reference see section Superficial Test Coverage @
Anshul,
I do not think a reference for the intricate problems we face with the
hierarchy of the CitrixResourceBase and descendants is fair to ask. I think
the burdon of proof is with you and not Rafael.
The tests do not just prove that the assignment works as in you example.
They prove that the fr
@anshul1886 I agree that we disagree.
Folks I do not know what to do in this case, I will not looking for
references to support what I said and did. Whatever you guys decided I will
do (remove or let the test cases there).
On Wed, Aug 19, 2015 at 9:47 AM, Anshul Gangwar
wrote:
> Let me summaris
Let me summarise the tests
class A {
x(){
return “d”; a constant
}
}
test
p=“d”
Assert( A.x() = p)
Which can be reduced to
class A {
q=“d";
}
Here q is replacement for x method as it is only returning a constant
now test is
p=“d"
assert (p=q)
To me this basically proves that java assignment
Can you point to any reference/blog which justifies writing tests for this kind
of scenario?
What I can infer from these tests is that that there are two scenarios
1) Method will not change
In that case it doesn’t make sense to put test for never changing method.
2) Method will change
In
@anshul1886 I totally agree with you that tests are meant to test
individual, and as you pointed the individual code that we want to test is
“getPatchFilePath”. However, that method is abstract, and its
“implementation” that is as simple as returning a constant, changes in few
subclasses of CitrixR
a unit can be defined at more then just the method level and in this case
those paths have changed from under us in the past. I am not justifying
testing any constant this way. I am justifying just this work.
On Wed, Aug 19, 2015 at 9:03 AM, Anshul Gangwar
wrote:
> What I mean to say is that uni
What I mean to say is that unit test are meant to test individual unit which
here is getPatchFilePath and not meant to test hierarchy as you are pointing
out here. By individual unit I mean it doesn’t matter for test that it is in
class A or class B. This way you are kind of justifying that we s
On Wed, Aug 19, 2015 at 5:56 AM, anshul1886 wrote:
> If the purpose is to make sure that path is not modified by other
> developer then adding note/comment on top of that line makes more sense.
> Even adding note is kind of implicit as paths are kind of constants which
> any developer would think
10 matches
Mail list logo
