August 24, 2015 at 11:58 am
Steve Jones - SSC Editor (8/24/2015)
Jeff Moden (8/21/2015)
Heh... who tests the unit test code to make sure that's right? 😉The developer, other developers, whoever. If it's not, change it. Tests aren't, nor should they be immutable. Nor should they even always be used. If it's a bad test, as the team determines, throw it away.
Don't get silly with saying who checks the checkers that check the workers. Who tests your code? How do you know it's right? However you determine it's right, that's a test. I'm saying automate that, don't expect that developers will always run that check when they change code.
Not getting "silly", Steve. It's a real and very serious problem. I'm going through this "silly" crap with bad tests on a project right now. 😉
--Jeff Moden
August 24, 2015 at 12:13 pm
When I write unit tests, it gets run in both development and QA. Each unit test is a script that maps to a specific functional requirement. A test plan lists the sequence that the scritps are to be run, including any prerequisite (ie: a client named 'ABC' should exist) and expected outcome (the script should return 3 orders totaling $12,550).
unittest_2-1.sql
unittest_2-2.sql
...
I run the test plan in development, and someone in QA runs the same test plan in QA in parallel. The scripts that query expected outcomes should have matching results between the two environments.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 24, 2015 at 2:26 pm
Eric M Russell (8/24/2015)
When I write unit tests, it gets run in both development and QA. Each unit test is a script that maps to a specific functional requirement. A test plan lists the sequence that the scritps are to be run, including any prerequisite (ie: a client named 'ABC' should exist) and expected outcome (the script should return 3 orders totaling $12,550).unittest_2-1.sql
unittest_2-2.sql
...
I run the test plan in development, and someone in QA runs the same test plan in QA in parallel. The scripts that query expected outcomes should have matching results between the two environments.
+1
In some cases You might need to "formally" create a mapping document so that your widget's unit test can be assigned to a specific sub-function (where you've "assigned" part of a larger function to that particular widget, and if that widget perform its part of the job - then the whole job falls apart.) This would even work on all of the non-functional aspects as well (e.g. in order to provide all billing info within 10 seconds, I need the database query to retrieve the billing detail in .5 sec).
But either way - if you "know" this data is good and you get a bad outcome on the test, then either a. the code is bad, or b. the test is wrong.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 24, 2015 at 2:43 pm
Matt Miller (#4) (8/24/2015)
Eric M Russell (8/24/2015)
When I write unit tests, it gets run in both development and QA. Each unit test is a script that maps to a specific functional requirement. A test plan lists the sequence that the scritps are to be run, including any prerequisite (ie: a client named 'ABC' should exist) and expected outcome (the script should return 3 orders totaling $12,550).unittest_2-1.sql
unittest_2-2.sql
...
I run the test plan in development, and someone in QA runs the same test plan in QA in parallel. The scripts that query expected outcomes should have matching results between the two environments.
+1
In some cases You might need to "formally" create a mapping document so that your widget's unit test can be assigned to a specific sub-function (where you've "assigned" part of a larger function to that particular widget, and if that widget perform its part of the job - then the whole job falls apart.) This would even work on all of the non-functional aspects as well (e.g. in order to provide all billing info within 10 seconds, I need the database query to retrieve the billing detail in .5 sec).
But either way - if you "know" this data is good and you get a bad outcome on the test, then either a. the code is bad, or b. the test is wrong.
Yes, I typically have the scripts print out the hh:mm:ss duration and statistics profile text plan too. The process of coordinating with business on a valid test plan also insures there are no missed requirements.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 26, 2016 at 1:46 am
Jeff Moden (8/24/2015)
Steve Jones - SSC Editor (8/24/2015)
Jeff Moden (8/21/2015)
Heh... who tests the unit test code to make sure that's right? 😉The developer, other developers, whoever. If it's not, change it. Tests aren't, nor should they be immutable. Nor should they even always be used. If it's a bad test, as the team determines, throw it away.
Don't get silly with saying who checks the checkers that check the workers. Who tests your code? How do you know it's right? However you determine it's right, that's a test. I'm saying automate that, don't expect that developers will always run that check when they change code.
Not getting "silly", Steve. It's a real and very serious problem. I'm going through this "silly" crap with bad tests on a project right now. 😉
Peer review.
Quis custodiet ipsos custodes?
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 5 posts - 31 through 34 (of 34 total)
You must be logged in to reply to this topic. Login to reply