Unit test -- especially in C++ -- require from the code under test to add more seams that would be strictly called for for a given problem.
Only if you don't consider testing an integral part of problem solving. For any nontrivial problem, it ought to be, not only in the software world.
In the hardware world, this has been learnt long ago - in the hard way....
This answer has been updated for UML 2.5.1 specification.
First, it appears that the notation is valid.
Actors (18.2.1) can only have Associations to UseCases, Components, and Classes and these Associations must be binary.
The relationship between Admin and User is Generalization (defined in 9.9.7). It is a specialization of the DirectedRelationship (...
For a good start to reading see this wikipedia list. Ideally, you are looking at separation of concerns. While a more general solution has advantages for reuse between projects, there is a problem.
The database is concerned with storing the data, and so it is the job of the database to know what the data is. You don't want a table that can store anything ...
As usual, the answer is: it depends. There are lots of issues to consider, including:
first and foremost, what the customer wants and is willing to pay for
the difference in implementation and maintenance cost and risks between the alternative solutions
the expected lifetime of the product
the expected scope of future changes (i.e. is it reasonably expected ...
I am going to throw The Way of Testivus at you, but to summarise:
If you are spending a great deal of time and energy making your code more complicated to test a single part of the system, it may be that your structure is wrong, or that your testing approach is wrong.
The simplest guide is this: What you are testing is the public interface of your code in ...
Why not a generic class that works for any type of statistics? So that you always have a single class.
public class Statistics<E>
private E element;
private int projectCount;
Statistic<Customer> myStCustomer = new Statistic<Customer>(...)
Statistic<Country> myStCountry = new Statistic<Country>(...)
You are giving far too little context to make that decision.
That said, whether to model things as different classes of the same class has little to do with how many different fields they have, and very much with how you expect to use them in your program. The canonical example is a Point class with Cartesian versus polar coordinates; both will probably ...
My answer ultimately is similar to Péter Török's in that I believe it depends on the additional effort and complexity of implementing the Generalized solution.
Framing this as a implementaiton argument though is a mistake, and labeling the two opposing sides by programming language and defining that in the way they think is dangerously close to creating the ...
TDD and Unit Testing, is good for the program as a whole, and not just for the unit tests. The reason for this is because it is good for the brain.
This is a presentation about a specific ActionScript framework named RobotLegs. However if you flip through the first 10 slides or so, it starts getting to the good parts about the brain.
TDD and Unit ...
Based on what you've written above, I would be inclined to approach the problem in the following way:
As you are retrieving the cities from the ResultSet, allocate each CityRecord a unique identifier (let's assume the type is CityId).
Put these records into some sort of Map that allows you to lookup a CityRecord by its CityId.
Have three separate Maps that ...
I would prefer to factorize the commonalities between two use cases using generalization relationship between use cases.
The use cases Phone Order and Internet Order are specializations of the abstract use case Place Order (in italics).
In other words, generalization is used when you find two or more use cases that have commonalities in behavior, structure,...
testing the smallest isolatable unit of an application
this is true, but if you take it too far it doesn't give you much, and it costs a lot, and I believe that it is this aspect that is promoting the use of the term BDD to be what TDD should have been all along - the smallest isolatable unit is what you want it to be.
For example, I once debugged a ...