8

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?

LazyCoder
  • 607
  • 4
  • 11
  • 3
    This really depends on what everyone's responsibilities are. In general, yes, you must confirm your changes before the test team gets it, but there are situations that can make this impossible or impractical. Discuss it with your supervisor or test team. – Robert Harvey Jul 07 '17 at 22:46
  • Apparently the unit test doesn't restore databases, check firewall rules, etc. So the test is probably not as complete as actually having it work on your machine. – RemcoGerlich Jul 09 '17 at 20:47

5 Answers5

8

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.

Telastyn
  • 108,850
  • 29
  • 239
  • 365
  • 2
    Keep in mind, if the unit tests run on your machine, they can still fall victim to works-on-my-machine bugs in the tests too, no silver bullet. – whatsisname Jul 08 '17 at 08:11
  • @whatsisname You're absolutely correct. However, unit tests when paired with an automated mechanism for running the tests (CI, pre- or post- commit hooks, etc.) usually requires that the running environment be clearly defined, which removes a lot of uncertainty. – Iker Jul 08 '17 at 08:37
  • 2
    If they're better heavily depends on whether there's any decent coverage of the affected modules. – Martin Ba Jul 08 '17 at 12:14
  • @martinba - yes, there is the implicit assumption of competent unit testing. – Telastyn Jul 08 '17 at 13:19
8

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.

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • 1
    Exactly, I've had unit test pass with flying colors but the app won't deploy because I screwed up something in the configuration. – Chris G Jul 13 '17 at 16:02
3

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.

Glorfindel
  • 3,137
  • 6
  • 25
  • 33
Lassi Autio
  • 283
  • 1
  • 3
  • 9
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.

gnasher729
  • 42,090
  • 4
  • 59
  • 119
1

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.

hotpaw2
  • 7,938
  • 4
  • 21
  • 47