I have a book which mentions:
"There are many types of testing, including unit testing, integration testing, functional testing, system testing, performance testing, and acceptance testing".
It is often noted that many developers carry out unit-testing only, or no testing at all. From the types of testing above, which ones are to be conducted by the developer? What are the responsibilities of a developer when it comes to testing?
The way you formulated your original question, I think you were approaching testing the wrong way and make too big a distinction between kinds of progammers and their roles, and making assumptions on the link between a language and the testing taught.
All languages allow for all kinds of testing. They may have built a more in-grained culture around testing, and may provide more tooling, and have some language features that facilitate it. And it's true that if you were to conduct a literature review, mainstream books about testing may have been appearing around Java's introduction and rise to fame, and relying on it to illustrate their points.
But all languages allow for testing of all kinds.
So, now, to try to answer your original questions:
What other testing does a Java Developer do from a Java Developer's Perspective?
and
As I have already mentioned every Java Developer carrys out Unit Testing. From the 1's I have described above, which 1's are done from a Java Developer's Perspective?
All the ones you've listed afterwards in your answer:
Of course, depending on your company some of the tests may not necessarly need to be performed by you. For instance, accpetance testing or performance testing are quite often left to other teams.
Plus, some testing may be done as "black-box testing", in which case it may even be best than you don't know the internals (or you may not have a choice to know at all), and in that situation it is of course less relevant for the original developers to be part of that testing effort. But they can still add their input, and they are likely to approach the problem in ways others may not have thought of.
However, I'd strongly recommend that developers, of any kind, participate in all testing efforts themselves or by directly working with whoever performs the testing in close-knit relationship.
Most of the times, software shops host separate testing and development teams do it for the wrong reasons, or because they are kind of pushed into it (or feel lile they're pushed into it) by the development lifecycle and their methodology.
It's not a fatality and can be changed.
Also, some testing can sometimes be done on top of existing efforts by non-developers. It's best to even advise your clients to perform their own acceptance testing and performance to validate your results. And you definitely should press them hard to get involved in that, so you can make sure they know what they want, and that you know what they will expect from your deliverables!
A final note: testing is only relevant if you know what to test and how to interpret the metrics and results they deliver.
Boris Bezier says this:
"Programmers are responsible for software quality – quality in their own work, quality in the products that incorporate their work, and quality at the interfaces between components. Quality has never been and will never be tested in. The responsibility is both moral and professional."
If you are responsible for delivering quality software, how are you going to do that? The software must be tested. If you are in an organization that doesn't have dedicated testing resources, it is up to you. Even if your team does have testing resources, it's up to you to make sure testing happens. That may mean writing tests, or it may mean you follow up with whomever is responsible for writing the tests.
Bottom line: you and your team are responsible for the quality of your code.
"What are the responsibilities of a developer when it comes to testing?"
The explicit responsibility is:
However I have found that the implicit responsibilities are:
Testing is about verifying the correctness of your work. I think it's every developer's responsibility to do that.
I suspect that the author of that quote was primarily talking about automated testing. There's also manual testing, which is probably something that you're doing already.
What steps to you perform to verify that the code you wrote works? If those steps can only be performed with your participation, then you're performing a manual test. If those steps can be run while you check twitter, then you're performing an automated test.
If I assume that your question is actually:
What are the responsibilities of a developer when it comes to [automated] testing?
Then my answer is that you've got to make that decision for yourself. The rule I follow is based on "3 or more use a for". I'll tolerate running a manual test twice, but the third time that I go to run it, I force myself to take the time to write an automated test. I recommend developing a similar rule that you can follow.
Depending on the type and size of your project, at least do "unit testing" of individual functions, then try to do some "system testing" i.e. put test data in the database, start the application like it would be done in production and compare the output with a saved copy of what you would expect. Between those ends there's "integration testing" where you test e.g. if some classes work together. Despite the name, you can do every kind of testing with the "junit" tool.
