Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
How do we future proof our code against changes in third party libraries? Maintaining unit tests seems like one way of going about it.
1) Configuration management. Knowing exactly what versions of your libraries go into making up your build is essential. Some distributions are very sloppy in identifying versions, so you may want to invest in a good version extractor, such as http://www.jboss.org/tattletale -- also, comparing reports over time so that you can identify what has changed in your libraries.
2) Unit tests and integration tests. The phrase "unit test" is badly misused in the community. You need to test a spectrum of behavior in your configurations.
3) Managing interaction effects. One of the toughest issues to manage is upgrading just one item. Often, point releases of libraries depend on other point releases of other libraries. You can't just take one.
4) Planning for systematic upgrading. Build into your project schedules work to do testing of newer releases so you can estimate the impacts of doing an upgrade. With that information, you can plan your upgrades for a time when you are not under the gun because it has gotten too old, or is incompatible with the next supported JVM.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
If one joins a new project, how should that person approach it if
there is no documentation of the code and program is quite big to understand. Team members are also not that much informative.
Should the person debug the code line by line?But it can be highly time consuming and exhaustive.
There are several options:
Look for manuals. I have seen projects without specification and developer documentation, but had a manual.
Participate in a training, if offered by your company. This may take some time, e.g. the next training is in 2 months.
Run the code and see what it does.
get a tool like NDepend that visualizes the dependencies. By that, find the central modules or classes. Look at those first.
Ask your developer colleagues. If they don't want to tell you, tell them that you need some understanding in order to do your job
If all of the before does not help, ask your boss for help. He should have a plan to get you productive.
The users option would be great, but in all companies I worked for I did not have access to end users as well, since we always worked with partners as intermediate resellers. Contacting the partners is not a good idea, because it might leave a negative impression if you don't know the software.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In our current project, we don't actually practice unit testing. Our bosses are encouraging us to go for build automation like Jenkins. Will a build automation tool really help us in productivity or quality?
It will probably help a bit, but not as much as with tests to back it up.
For example, build automation, if configured for every attempt to submit code, will ensure that if the build fails, i.e. can't compile, then either the code is prevented from entering the main branch where everyone else is working or at the very least, make sure everyone is aware the build is broken. This depends on whether your build automation runs before or after the code is merged to the branch everyone else is working on.
This would ensure that at a minimum the code at least compiles, and therefore that others on the team don't have to wrestle with code that doesn't compile and lose time trying to pinpoint errors in other code.
Depending on how much build automation is included, you might even have deliverable artifacts ready to be manually tested which saves the time of performing those builds.
But that's about the limit of it, unless you have some tests.
As a side note, the reason I said probably, is none of it is worth anything unless attention is paid to the results. If the results are there but never really followed up on, then the reality is zero value.
Sure, automating your build will improve your productivity and quality even if you haven't written any tests yet. You won't have to build manually every time someone wants a build to test or release, and you'll find out faster if you have a compilation or other build error.
But you should certainly write tests as well, and run them automatically too.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What i have done :
Created few projects using Java/ Selenium Webdriver/ TestNG using eclipse
Getting the TestNG test results in an XML/ HTML formats and looking for failures etc.,
What i can look for hereafter,
Do i need to use Maven(or likely tools), for managing projects, and why?
Do i need to look for Jenkins type of tools(But i know it depends on context, still if there will be any real usability with selenium webdriver)
Do i need to look for reporting tools(such as surefire) which is well equiped?
Or is it ok to continue with what i'm doing for a not so complicated project?
I know this qustion may be really broad, but i don't find anything solid to look after.
Appreciate your help, Thanks!
I think the world has agreed that Continuous Integration is good which is pretty rare for any technology.
I would definitely suggest setting up jenkins or equivalent and adding the maven configuration to be able to get your project to run and store results there. This may end up being more work because ideally you want to get the project you are testing to be built on check in and have its unit tests etc to run and then get deployed so you can run your selenium tests.
It shouldnt take too long to do depending on the ease of deployment of the app your testing, but even just having your tests being able to be kicked off automatically and its results stored will be handy and give you a real visibility boost of your tests.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
At our company we're taking a critical look at the products in our Java Development/QA street. One of the products we're looking at is Apache Continuum.
Could someone with Continuum experience (and preferably also Jenkins experience) explain what the advantages and disadvantages of Apache Continuum are (especially with regards to Jenkins)?
My first impressions are:
Advantages:
Better suited for grouping builds and projects (from a UI perspective).
Disadvantages:
No clear dashboard.
A relatively small community.
No plugins (right?).
We are using continuum and we switched to jenkins.
Jenkins advantages:
Findbugs
pmd
checkstyle
code coverage (very good chart see for emma)
integration with artifactory
integration with sonar
post build task (build other projects, automatic archiving)
new delivery of jenkins every week - critical bugs are solved very quickly
rpm/deb packages (you can use yum/deb for automatic update every week)
In jenkins you create the view and you can group projects there.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Is anybody out there using Project Lombok for a large scale production system? How does it influence your compile process (i.e. does it do two-pass compilation, slow it down, make it more fragile)?
Lombok doesn't do two-pass compilation. Technically it 'slows down' the compile process in that it runs in addition to the usual things that occur when you compile, but compared to the parse phase, the lower phase, and the translation phase, lombok barely even registers.
The major fragility issue is that editing lombokified code in an editor that is NOT either (A) dumb (i.e. notepad or a diff viewer), (B) eclipse, (C) netbeans, or (D) gets all its brains by running javac (e.g. vim with java plugin), it's going to suck. If that doesn't apply, the reduction of boilerplate should only make your code less fragile.
DISCLAIMER: I'm one of the two main developers of lombok :)
I used Project Lombok whilst developing a Google Web Toolkit (GWT) front end for large java & Swing UI application. As I did not use #SneakyThrows, I did not require lombok.jar at runtime.
Using the delombok behavior I provide a 2stage compilation process.
Lombok annotated java code => Java code => Javascript
In terms of suitability for large java projects, delomboking the code for the web front end takes less than 2 seconds, the rest of the gwt-compilation process takes ~50 seconds (These metrics are taken from a developer work station).
We are considering this week if we will provide Lombok support to the rest of the application. Building the main application takes around 1 hour (including unit tests, installers etc built on a box with 2xIntel E5450's).