re: Things Nobody Told Me About Being a Software Engineer VIEW POST

TOP OF THREAD FULL DISCUSSION
re: 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...
 

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.

 

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.

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

That’s why you should

  1. Write a failing test
  2. Make the test green by implementing
  3. Refactor Go back to 1.
 

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.

 

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 (infection.github.io/ 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 :-)

code of conduct - report abuse