Add a comment

 

Re: Unit and integration are ambiguous names for tests

I agree that a shared vocabulary is missing. This is one precise way to talk about tests by focusing on what is being tested. My primary method is to talk about tests in terms of their purpose: - Unit Tests - they certify that code works the way you expect it to work. I also like to call them specs - for how the code is expected to work. - Functional Tests - they certify that product works the way you expect it to work. Testing is done through public interfaces (UI, API) and from user perspective. If you use BDD then you can also look at BDD scenarios as specs. - Non-functional Tests - they certify that software is operating the way you expect it to operate. Things like performance, resources utilization, etc. go here. Overall, the purpose of testing is to certify software to be released to production according to whatever certification criteria are deemed appropriate by the team (they will legitimately vary from product to product). We automate all aspects of software certification and delivery (no manual testing whatsoever). What I have noticed is that, when all testing is automated, with new products the split between tests is about 90/10. 90 for unit tests, 10 for functional/non-functional. Another thing that I have noticed is that most functional testing happens at system level, only basic testing is done at component level.

Re: Unit and integration are ambiguous names for tests


Title
Body
HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).