Can a unit test replace works-on-my-machine when completing work?

Question

I've made a small change to an integration component and have prepared unit tests to cover my work. All new and existing unit tests are passing.

It will take a substantial amount of time to configure and run the component locally as I will need to restore databases, check firewall rules etc.

The definition of Done in terms of development work is unclear.

Is a unit test a better replacement for works-on-my-machine?

Is it seen as unprofessional if I do not confirm the changes manually before passing work over to a test team?

Answer 1

Is a unit test a better replacement for works-on-my-machine?

Yes, it's absurdly better. Unless you've got some sort of containerization to guarantee the configuration of your environment, running on your local machine guarantees nothing. And even then, doing it by hand is just asking for others to screw up doing the same thing by hand. Unit tests verify that the functionality itself works, quickly, reliably, repeatably.

Is it seen as unprofessional if I do not confirm the changes manually before passing work over to a test team?

It can be. Different work environments have different standard operating procedures and expectations. I expect that most environments either wouldn't care that you only ran the unit tests or wouldn't care enough to know that you only ran the unit tests.

Personally, I'll only manually verify things that are for some reason prohibitive to unit test or being picked up by an abundantly sensitive stakeholder.

Answer 2

No. You need an integration or UI test to verify the whole thing works.

Ideally these are performed on some sort of test environment rather than your own machine though.

If you lack that, its probably worth going through the setup and testing it manually. After all its a one time thing for that system right?

Use a virtual machine and save the image for reuse.

Unit tests are great, but they wont catch basic stuff like configuration which will break the system just as bad as a mistake in your code.

Answer 3

It's a matter of cost. Say your code has to work in six significantly different environments, and your unit tests are set up to check all these environments. And it would take you six hours work to set up one of these environments on your machine.

In that case it would make absolute sense that you check the code on your machine as it is set up (to find bugs that happen in any environment) and then run the unit tests. You may be able to do three rounds of unit tests and fixing broken tests in the time it takes you to set up one environment.

Answer 4

Unit tests are a good addition to works-on-my-machine.

You should always run integration/manual tests as well. It is a bad thing to do only unit tests.

A good way to make code "works also in your machine" is to have a test server and continuous integration like Jenkins. That way, the code will also be run on other machines.

Answer 5

Depends on your team's policy.

Local user testing may cover different code paths than your provided unit tests. And more coverage is usually better. Anomalies seen in "does-it-work-on-my-machine" testing sometimes points out the need for additional unit tests or other test procedures.

But your teams policy may be that that is someone else's job. Or, in small teams, it might actually be your job to make sure something works outside just the test environment.