Unit Testing #1656
Replies: 2 comments 13 replies
-
The answer depends (can you tell I work in consulting? 😉) on exactly what you mean by "unit testing". "Real" unit testing generally won't test domain types, because you should be testing your business rule types, and maybe testing to ensure that the right rules are being associated with various properties of your domain class. Determining whether a rule is associated with a property can be done without invoking the properties, because you can interrogate the rules engine to see which rules are associated with each property. What most people actually do is some level of "integration testing", where they create an instance of a domain type, reading/writing properties, and checking the result. This actually is a long way from unit testing, because this sort of testing invokes the data portal, probably invokes persistence, and also invokes business rules - but within the context of simulated UI binding. The way you implement unit testing is different from integration testing. And even within integration testing, there are various levels of abstraction/complexity you can choose - ranging from high level testing, down to very sophisticated mocking of things like the data portal. |
Beta Was this translation helpful? Give feedback.
-
@rockfordlhotka , agree about the integration testing part, my unit tests are technically integration tests. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I have been a CSLA user since v3.0 and have used it upto v4.0 but have been not in touch for the past 1-2 years.
Coming back to my query, I have download the v5.2 and am able to run the projecttracker sample.
But I am unable to unit test the business objects (projectedit, projectlist).
What is the right approach to do so and what methods is everyone else using.
Any sample code would be a great help.
Thanks
Prithvi
Beta Was this translation helpful? Give feedback.
All reactions