what is really hard is testing - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Java - 爪哇娇娃

what is really hard is testing

what is really hard is testing# Java - 爪哇娇娃

c*n2013-07-31 07:07

1 楼

recently went through a lot of spring code testing, using mocks and in-mem
h2 db.
spring is kind of a mess, u declare a @component, and then it becomes global
accessible to everyone. as u accumulate more and more library dependencies,
all those @component (or those beans declared in the contexts) become like
trash to you, it's almost like the global variables in C coding days

w*z2013-07-31 07:07

2 楼

DI is useful , but sometimes it is a bit messy, hard to know what is going
on. I have seen big applicationcontext.XML with hundreds of lines, bit
painful going through it.

global
dependencies,
like

【在 c******n 的大作中提到】

: recently went through a lot of spring code testing, using mocks and in-mem
: h2 db.
: spring is kind of a mess, u declare a @component, and then it becomes global
: accessible to everyone. as u accumulate more and more library dependencies,
: all those @component (or those beans declared in the contexts) become like
: trash to you, it's almost like the global variables in C coding days

g*g2013-07-31 07:07

3 楼

I don't quite understand your complaint. It wasn't like the alternative is
easier to test. @Component is like a global service that has namespace, that
's much different from global variables. With mockito you can inject mock
dependencies for unit test.

global
dependencies,
like

【在 c******n 的大作中提到】

c*n2013-07-31 07:07

4 楼

--- "@Component is like a global service that has namespace"
what is the namespace ?
if in 2 libraries, written by 2 people, both mark
@Component
public class AuthorA implements SomeInterface {
}
@Component
public class AuthorB implements SomeInterface {
}
now in my application code, I just want to grab an "author", and do
public class MyTestSuite {
@Autowired
SomeInterface blah;
...
}
here since AuthorA and AuthorB are both discovered as "@Component", they are
like global variables, and makes my test fail to resolve the auto-wire of
SomeInterface. well my complaint is not really about tests only, just that
I found these issues during tests. my point was more "it's difficult to
provide a set of tests that prove that your code works given this huge
global context containing everyone's trash beans "

that

【在 g*****g 的大作中提到】

: I don't quite understand your complaint. It wasn't like the alternative is
: easier to test. @Component is like a global service that has namespace, that
: 's much different from global variables. With mockito you can inject mock
: dependencies for unit test.
:
: global
: dependencies,
: like

g*g2013-07-31 07:07

5 楼

The namespace is the classname, which is global unique.
An interface implemented by two classes, while commonly seen, is not gonna
be the majority of your beans. And you can always use @Qualifier

【在 c******n 的大作中提到】

: --- "@Component is like a global service that has namespace"
: what is the namespace ?
: if in 2 libraries, written by 2 people, both mark
: @Component
: public class AuthorA implements SomeInterface {
: }
: @Component
: public class AuthorB implements SomeInterface {
: }
: now in my application code, I just want to grab an "author", and do

c*n2013-07-31 07:07

6 楼

that is not a proper namespace, it's exactly the same false argument that u
can make global vars work by giving them "unique" names

【在 g*****g 的大作中提到】

: The namespace is the classname, which is global unique.
: An interface implemented by two classes, while commonly seen, is not gonna
: be the majority of your beans. And you can always use @Qualifier

g*g2013-07-31 07:07

7 楼

It's global service, not global variable. I don't think OOP is against
global service. And as I said, @Qualifier can solve your problem.

u

【在 c******n 的大作中提到】

: that is not a proper namespace, it's exactly the same false argument that u
: can make global vars work by giving them "unique" names