Originally posted by Reza Rawassizadeh:
OK so for my usage(just know it and don't need to work with it deep) I prefer to read my lovly "Thinking in java".
After I read 115 page of JUnit Recipes, I don't find anything about teardown() so I don't find it interesting book (from my point of view).
Originally posted by Don Kiddick:
I don't see much advantage of FitNesse over unit testing then...apart from the communication aspect of the wiki. Or am I missing something ?
Let�s supose that it�s necessary to validate an student�s school registration.
validateXXX is a part of the whole validateRegistragion. They don�t have a real meaning by themselves but they are complex enought to deserve to be tested.
I wouldn�t like to expose them JUST because i want to test them.
What do you suggest me to do ?
Originally posted by Rickard Johansson:
I have heard people say that the argument for only testing the public interface of a unit is that you will be able to refactor the internal structure of the unit without having to change the tests. I guess that this comes from bad experience in projects where test discouraged people from doing codechanges since they would also have to rewrite the test (i.e. more work).
I myself find this a bit strange since a solid testbed should give developers the courage to refactor code and be confident they did not break anything.
1) Agile stresses testing-first where a unit/functional test is built before and engineer writes the application software. UGOT says "test first" is a good idea but it is optional. UGOT is not nearly as militant as Agile sometimes comes across.
2) UGOT provides a decision maker with actionable knowledge to decide when a service is ready for production. UGOT provides:
- Functional test to check for regression and successful operation.
- Scalability testing for capacity planning. Scalability is stated as a function of throughput measured at the consumer/client in requests-per-second as the number of concurrent consumers/clients increases. This shows that the system has enough capacity to serve forecasted levels of users. (See http://www.pushtotest.com/Docs/howto/onscalability2.html to see how I have been plotting this for our customers. I'm open to feedback/criticism.)
- Performance testing to make sure the service meets user expectations for response times. A 3 tall mocha latte's a day person isn't going to wait more than 5 seconds for their email client to check for new messages.
3) Bret described "coaching tests, a way of thinking about Acceptance tests" that turn user stories into tests. UGOT identifies archetypal users by their behavior when using the service. By understanding the archetypal users behavior, we can then write test agent code that drives the service, as the archetypal user will.
Java Testing and Design shows the reason why building archetypes is important to a business, how to go about doing it, and then how to repurpose them between developers, QA technicians, and IT managers.
Java Testing and Design puts forth User Goal Oriented Testing (UGOT.) UGOT is a testing methodology that models the behavior of archetypal users of a service. In the book I show how to understand these behaviors and how to turn them into test agent code. The resulting code does a functional test of a service. The functional test is intelligent since the test requires multiple calls to the service to accomplish the user's goals. Rather than testing every function of the service, the UGOT method tests the service against the goals of the archetypal users. This has worked really well with GM, Sun, and others. The book covers three case studies.
Why, in your opinion, are tiger's new
features described by Schildt undermining the
distinctive characteristics of Java?
Bare in mind I don't know C++, but I'm trying
to understand your preoccupation.