Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!

Alexandru Popescu

Ranch Hand
+ Follow
since Jul 12, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alexandru Popescu

I was thinking more about greenfield projects when I made my previous post.



Makes sense, but wanted this clarified for the OP. Also, my understanding of his post is that he is not working in fact on new projects ;-).

BR,

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator
12 years ago

As a variant of this - if I write a low level class that contains a bug and it can't reproduced through a functional/integration test, is it still a bug?



Yes, it is. Unfortunately, there will always be bugs, and I really don't think there is something we can do about it :-) (not even the so called 100% test coverage will find them, because most of the time this 100% is what we can imagine to be 100%, not what real world uses as 100%).


It's hard to prove things. And even if you can, you need people to feel that testing is important. This is true for unit or functional/integration testing in JUnit or TestNG. People write better tests if they buy into why testing is important and aren't just doing it because someone told them they have to.



My point is: the developers will do something that makes their life easier. I will always fear to ask my team to do something that makes their lifes even more complex. For a team it is easier to see the benefit of functional/integration tests (if these are enough easy to be developed maintained), rather seeing the benefit of unit testing (and if we get to mocks then I am hearing their questions :-) ).

Many people who don't write unit tests believe that functional/integration testing is sufficient. I certainly did four years ago.



Frankly speaking I do like more these and I encourage teams to have at least these in place (and most of the time I can proove their importance and the fact they are paying back the effort). Still, I am not saying unit tests are not good.

As the person who suggested this, I meant for it as a short term measure. It is still important to get people to agree the tests should always work even if they aren't writing them yet. I actually had some success with this because it was easier to get people to agree that "tests are good and should run" than that they should write the tests. Then once some tests are in place, the benefits start to show themselves. And of course, sometimes this will fail. That's why there isn't any one answer we can give - it depends on your team.



Unfortunately, my experience is quite different. Under pressure, the first thing done is to disable them. And that's the end.

I think there are many more cases where unit testing proves useful than when it doesn't. I think it goes by product, not team though.



I will not argue on this, but I would encourage you to listen to Venkat Subramaniam on Pragmatic Agile Adoption]Venkat Subramaniam on Pragmatic Agile Adoption and see what I meant.

BR,

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator
12 years ago
That's a very interesting topic and I've been reading all the suggestions in this thread. However, I feel like playing the devil role :-).

So, I will start by asking: can you proove to your collegues that writting unit tests will help them out? (and by "them" I mean each developer, and not the team, not the product, not the project manager, etc.). One hint in this direction was given by Ernest Friedman-Hill when saying:

write unit tests or debug


(even if I am enjoying doing either with the right balance ;-)). Can you show them that by righting an unit test they will have an easier way to fix a bug or your bugs can be reproduced only through functional/integration tests?

However, for the moment, I guess the answer to the above question is no, because otherwise you wouldn't be asking the question here. Now, you should answer yourself why cannot you proove that unit tests will help them out. And as far as I can imagine the answer would be in the following range: the code is not easily unit testable, so writting unit tests would make them work more. If this is the case then you will have much more work to perform: introduce a shift in the way your software is written so that testability becomes more simple (and this is a very long topic). The other side of the answer can be: our business logic is so little as unit tests do not pay back the effort and we prefer doing higher level functional/integration testing as this is the part that is complex enough to be tested. And in this case, I would recommend you to leave it this way, and just look into ways to improve the quality of these test so that they survive and remain valid even after a release (shameless plug: you can take a look at TestNG).

As regards some of the suggestions made in this thread, most of them will work, but sometimes will also fail (f.e. be the first one writting unit tests. You can do that, but if the code is changing too fast and the tests will start to fail a couple of times per day, people will disable them, and you will be the only one fighting with them; moreover you will be the only one to work on them and so you will have less and less time left to implementing real stuff).

I know I am not giving the kind of answer you would expect. But I am a pragmatic developer and I don't believe in silver bullets. Unit testing may proove usefull to some teams and products, but it can also be an unneeded expense on others.

cheers,

./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator
12 years ago
He he... this seems a last minute news from ML. Thanks Matthew.

--
:alex |.::the_mindstorm::.
A wild guess: it may be a problem with the Layout and LayoutData you are using.

--
:alex |.::the_mindstorm::.
14 years ago
Matt EclipseWork seems pretty interesting, but I think that the project hasn't got a release yet.

--
:alex |.::the_mindstorm::.


Spring and Struts, etc. are J2EE compatible in the sense that they utilize parts of J2EE, such as Servlets.



Any web application that must be deployed inside a servlet container must use in a way or another Servlets, Filters, etc. .

But when talking about compliance with specs, I mean: can you take one application developed with Spring (f.e.), decouple Spring and than deploy it without modifications in WebLogic?

As Stefan is saying they are extensions to the specs. It's like using the WebLogic (or WebSphere or any other) extensions, with the single difference that these are not redistributable.

--
:alex |.::the_mindstorm::.
I guess you are refering to the icons found in rt.jar: com/sun/swing/plaf/*/resources. From there you can load it as any other resource found in your classpath.

--
:alex |.::the_mindstorm::.
14 years ago
What is your createImage() method really doing?

--
:alex |.::the_mindstorm::.
14 years ago
WW1
I suppose the book is focusing just on WW2, ain't it?

--
:alex |.::the_mindstorm::.
The solution sounds good. Maybe a better one would be to have all the inputs READ-ONLY for a read-only user and also the Submit button absent. This way the user will not get pissed off after modifying the data and not finding a way to submit it.

--
:alex |.::the_mindstorm::.
Unfortunately Stefan this time I have to disagree with you: none of the above mentioned frameworks (Spring/WerbWorks/Hibernate/Struts) are *not* conforming to any of the J2EE specs. Maybe you can consider some of them de facto standards, but they are not developed according to the specs.

--
:alex |.::the_mindstorm::.
I will second Stefan's advise. In fact I will say that this was the way I've done it (but I must admit that in my case it was determined by the time: i have learnt j2ee firstly, cause at that moment there was no Spring, Behave, or any other IoC/DI lightweight containers). But when starting using Spring I have easily identified the issues/features they where addressing.

--
:alex |.::the_mindstorm::.
Matthew I am wondering what are the features planned to be supported by the plugin.

tia,
--
:alex |.::the_mindstorm::.|

ps: i am a newbie WW user, and for the moment I haven't feel the need of a plugin.
Ken I think the solution stays in using minimum and prefferedSizes for your components, and also specifying weights for the gridbaglayout cells.

--
:alex |.::the_mindstorm::.
14 years ago