0

I'm using nose with django-nose for my tests

But , I'm having troubles ordering my tests in a smart way

It's said that nose execute tests in alphabetical order , however , this is not the case with me. no matter what i do (change my code order , function names , clear compiled files) .. The test runner choose the very same ordering .

i can of course divide this big test into function that i would call , but i believe there is a better way

What am i missing ? Did anyone face the same problem ?

Side information: I'm testing against a series of ~10 actions , so i would argue -especially in my case- against 'test isolation'; having to rewrite past actions for every test is just not the smartest , nor time efficient in my opinion... & this is where execution order should comes into place.

I'm aware this A Nose plugin to specify the order of unit test execution , But i cant "setup" the nose plugin correctly , nor the functin naming answer is working

Thank you indeed

Community
  • 1
  • 1
Ramez Ashraf
  • 873
  • 6
  • 14

1 Answers1

0

After almost 2 days in non stop researching , i decided that this was not the way to go , and mainly i dropped having this feature tested as a "unit test".

Did you know that setUp & Tear Down are executed for "every function" in your test case ?!! I Didn't !!! :)

i came to believe / understand that Unit test is for testing a unit (DAH!) meaning testing a function not several interrelated or "complicated" class that do compute and update db ...

Such stuff, and what i want to test, falls in another category , "Behavioral" testing . I saw this video very helpful Malcom talk on testing & behavioral testing and this package demo Behave

I'll post here how it actually went , Good luck you all

Ramez Ashraf
  • 873
  • 6
  • 14
  • Note that while unit test as a methodology is meant to test things in isolation, most unit testing tools does not actually prevent you from doing functional or behavioural or integration testing. If you want to share test fixture, you can use setUpModule()/tearDownModule(). Having said that, even with higher level testing, you should still strive to avoid order dependency. If your tests depends on each other, perhaps they actually should be a single big test instead. – Lie Ryan Apr 30 '14 at 11:02
  • Thanks Ryan , Yes Unit does not really prevent, but makes it REALLY HARD to do. I actually did make it in a one big huge unit , but then if one assert fails , i don't get to see if other tests would have succeeded or not. I also tried SetUpClass but lots of hassle regarding passing related variable around. Fixtures , were ... ehh .. to much hassle also as i'm in the start of a project so schema is so much subject of frequent major change. :) – Ramez Ashraf Apr 30 '14 at 11:37
  • Note that I wasn't referring to django's fixture; a "test fixture" is basically the state that you get after setUp* commands are called. Unit tests frameworks does not make integration testing any harder, integration testing is inherently hard. The issue is that you need to balance between a slow but thorough clean up and one that is fast but leaves stuffs that may potentially affect the repeatability of the test. If you abandon isolation, how would the test framework be able to know which tests can still proceed if the current one fails? – Lie Ryan Apr 30 '14 at 17:27