As I understood from some Q&A sessions (see this and this), unit tests should be written by developers.
At my previous workplace we tried to give this task to a QA Engineer, but it didn't work. May be because it was already a middle of a project and he didn't have a chance to do a significant code coverage or may be because of another reason.
Do you think it's a bad idea to free a developer from writing unit tests in a such way?
Generally, I think it is a bad idea. Unit tests guide the developer to write modular (and therefore useful, reusable) code because their code needs to work with both the production system and the test code.
Yes.
A developer writes the unittest te ensure that the "unit" does what it suppose to do. A QA person test the whole application.
Besides, a unit test is code, and developers write code. Most of the times QA engineers don't write code.
I don't think it would be bad, I just don't think it would be possible. If the code wasn't written test first it probably isn't testable.
Is the QA person doing to refactor the code to make it testable?
If so, then that's fine, and I don't care what their title is. If they're not, then I doubt they'll be successful.
I think it's generally bad for QA to write unit tests. Unit tests are code, they are tightly related to how the dev code is constructed. For this reason, the developer knows best what tests would make the most sense.
On the other hand, I believe QA should stay as close as possible to unit testing. QA needs a good relationship with the dev and try to understand the code design. Why? When a developer is writing unit tests, the focus is still on development, not testing. You cannot trust (not in the bad sense) a developer to come up with the best test cases and that she has good coverage. Since QA is specialized in testing, it may be a good idea to keep QA and dev as close as possible during unit testing.
The developer has to write the unit tests. Otherwise it is like the developer doesn't have to care about the quality. In addition, unit tests help the developer to write better code.
Maybe you've heard about TDD? "Test Driven Development" is a really a good practice for development. Its main purpose is to develop unit tests before write the actual code (which is a strange thing, when we start using TDD, I admit)...
Having a person dedicated to unit-testing in a team can seem interesting at first sight ; as he will review all the code. This also would alleviate the risk of having one developer making the same error in the production code and in the unit tests.
However, in order to be unit-tested, the code has to be testable ; what can he done when the code it receives is untestable ? Rewrite it ? Refactor it ? Without Unit Tests ?
In short, I think this would not be such a good idea.