Thank you for your very useful article,
As I'm a Newbie in Unit Testing, I would be very grateful if you help me with my Unit Test issue:
Have a Method in which I register all my interfaces and classes (in a specific NameSpace) to be injected via my DI library (Here DryIOC), I want to write an UnitTest Method to check if all the interfaces and their inherited classes have been registered. this is the Method Under the Test:
Where can be found source code from the tested app?
Hmmm, I'm not sure I have it anymore, being that the intention of the article was to discuss unit testing, not the code being tested. But you're right, I should have provided that when I posted the article. This was originally from a book that I was going to write (years ago). I seriously doubt I have the code anymore!
* Testing and Test Control Notation Version 3
* Internationally standardized testing language
* Product of the ETSI Technical Committee MTS (Methods for Testing and Specification)
* A programming language that has been used for more than 15 years in standardization as well as industry
* Specifically designed for testing and certification
* Constantly developed and maintained at ETSI by a team of leading testing experts from industry, research institutes, and academia
* A testing technology that applies to a variety of application domains and types of testing
* Knowledge of TTCN-3 is valuable both for employees as well as employers due to its wide applicability
* Offers potential for reducing training and test maintenance costs significantly
* Proven to work in very large and complex industrial tests, e.g., of 3G network elements
I see this was written a long time ago but its concepts still apply.
I don't think enough credit was given to black box testing, but that is because it is intuitively easy to think white box testing is always superior to black box testing. Black box testing which only focuses on good values is rather worthless to be honest. A good black box testor will mentally reverse engineer the project in their mind and will be testing values which they believe will cause an error message, will put the program in an inconsistent state, or may cause incorrect behavoir if not handled correctly. A lot of the points you applied to unit tests could be elevated to white box testing in general.
Also, when I was taking software testing I was told that regression tests don't pay for themselves on the current release; they break even two major releases down the road. But I guess I see a unit test as a subset of a regression test.
Don't know if anyone is still discussing this article in 2007, but on brief scan it seems interesting, so here's one take on one specific point:
Excellent point about what Unit Testing, AUT, etc. often is and often is not good at. I think four things that Unit Testing, AUT, etc. are good for are:
-- Causing developers to think about what can go wrong with what they're coding, as they're coding it
-- Catching regression early
-- Capturing the developers' intentions
-- (To my point): Testing that ***developers' code meets the developers' intentions***
(Not a comprehensive list, in my opinion, but four important things. Also, I happen to be one of those 'drank the kool-aid' people who don't distinguish much between designers and developers)
Although I would not agree that ***the progenitors*** of the agile/XP/TDDD/etc. movement argue for AUT as a 'be-all, end-all' practice, I think unfortunately that many of ***the practitioners*** operate on that basis. So in a nutshell, the mistake is often made ***in practice*** of operating under the (explicit or implicit) assumption that AUT can capture gaps between the users' requirements and the developers' understanding of those requirements, which is not in fact the purpose of Unit Testing, nor of Automated Unit Testing.
So in a nutshell, the mistake is often made ***in practice*** of operating under the (explicit or implicit) assumption that AUT can capture gaps between the users' requirements and the developers' understanding of those requirements, which is not in fact the purpose of Unit Testing, nor of Automated Unit Testing.
People are just notoriously impossible. --DavidCrow There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
What an amazing article. It’s nice to see someone decompose and present the underlying functionality of Unit testing (NUnit) with such thoroughness and depth. These series of articles will definitely be highlighted on my blog. Thanks again Marc.
I really appreciate the NUnit Framework Testing Suite. Its solve a lot of problem for testing .NET Code. Kindly highlight the limitations and issues of NUnit before we make the NUnit ultimate choice for testing code.
> Question:i want to prepare an web site for evaluation
> in which automaticaly genrates the question from database
> i want to add facilities privious and next button in my web
> please give me code suggestion