DEV Community

Discussion on: Things Nobody Told Me About Being a Software Engineer

ruvans profile image
Ruth Evans

That I would be this suspicious when the tests pass on first try, and have to invert my assertions to force a test failure and convince myself that things are working as intended.

I thought only I did this! haha

darwinv profile image

that's fucking right hahaha

sturzl profile image

check out the mutation testing comments below, very helpful tactic to validate tests. Who guards the guards?

anaulin profile image
Ana Ulin 😻 Author

Fun fact: someone taught me that early on in my career as a best practice to make sure that my tests were actually doing something.

These days I try to always start by writing my test with an assertion that is guaranteed to fail, run the tests, verify that it does indeed fail, then rewrite the test to pass.

kyslik profile image
Martin Kiesel

Or delete some parts of the implementation and see if some tests fail. I sometimes split commits in test and implementation so I see failing pipeline.

Thread Thread
uzitech profile image
Tony Brix

My workflow is almost always:

  1. Write the code
  2. Write the test
  3. Run passing tests
  4. Comment out the code
  5. Run failing tests
  6. Uncomment code
Thread Thread
stealthmusic profile image
Jan Wedel

That’s why you should

  1. Write a failing test
  2. Make the test green by implementing
  3. Refactor Go back to 1.
furgas profile image
Tomasz Sawicki

Test Driven Development practitioner (I'm not) would probably sigh (at least) reading this. According to TDD you should first write your failing (obviously) test, and then write the code that would make this test pass. This way, checking that tests are actually doing something is part of the workflow.

ohffs profile image

Your list is great :-) I'm possibly old and cynical these days but I'd maybe add '...and nothing seems to be getting much better'.

On the testing side - I've recently started running 'mutation tests' on my code ( in particular). It's been quite eye-opening and a little depressing watching it flip 'true' to 'false' all over the place and tests still passing :-/. In my (feeble) defence, a lot of the time it's because in one test I'll be checking that related-fieldX has changed the way I expect and in another checking the true/false aspect - but it's still pretty eye-opening and has caught a lot of things I'd otherwise have missed :-)

Thread Thread
skyboyer profile image
Yevhen Kozlov
smallbellows profile image
Sara Given

When I'm assigned a bug and there's not unit test that covers it, the first thing I do is write the test that fails, and then go about fixing it. And usually along the way discover additional cases that would cause similar failure that hadn't been covered yet.