StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
8674766
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-12-29T23:40:31.853
FavoriteCount
0
LastActivityDate
2011-12-29T23:40:31.853
LastEditDate
LastEditorUserId
0
OwnerUserId
1094185
ParentId
8643867
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
I think the key here is what you should be testing. You've mentioned TDD in the tags, so I hope that we're trying to adhere to that here. By that paradigm, the tests you're writing have two purposes: <ol> <li>To support your code once it is written, so you can refactor without fearing that you've broken something</li> <li>To guide us to a better way of designing components - writing the test first really forces you to think about what is necessary for solving the problem at hand.</li> </ol> I know at first it looks like this question is about the first point, but really I think it's about the second. The problem you're having is that you've got concrete components you're testing instead of a contract. In code terms, that means that I think we should be testing interfaces instead of class methods, because otherwise we expose our test to a variety of problems associated with testing components instead of contracts - inheritance strategies, object construction, and here, renaming. It's true that interfaces names will change as well, but they'll be a lot more rigid than method names. What TDD gives us here isn't just a way to support change through a test harness - it provides the insight to realise we might be going about it the wrong way! Take for example the code block you gave: <pre><code>[TestMethod] public void GetCity_TakesParidId_ReturnsParis(){...} { // some test logic here } </code></pre> And let's say we're testing the method GetCity() on our object, CityObtainer - when did I set this object up? Why have I done so? If I realise GetMatchingCity() is a better name, then you have the problem outlined above! The solution I'm proposing is that we think about what this method really means earlier in the process, by use of interfaces: <pre><code>public interface ICityObtainer { public City GetMatchingCity(); } </code></pre> By writing in this "outside-in" style way, we're forced to think about what we want from the object a lot earlier in the process, and it becoming the focus should reduce its volatility. This doesn't eliminate your problem, but it may mitigate it somewhat (and, I think, it's a better approach anyway). Ideally, we go a step further, and we don't even write any code before starting the test: <pre><code>[TestMethod] public void GetCity_TakesParId_ReturnsParis { ICityObtainer cityObtainer = new CityObtainer(); var result = cityObtainer.GetCity("paris"); Assert.That(result.Name, Is.EqualTo("paris"); } </code></pre> This way, I can see what I really want from the component before I even start writing it - if GetCity() isn't really what I want, but rather GetCityByID(), it would become apparent a lot earlier in the process. As I said above, it isn't foolproof, but it might reduce the pain for this particular case a bit. Once you've gone through that, I feel that if you're changing the name of the method, it's because you're changing the terms of the contract, and that means you should have to go back and reconsider the test (since it's possible you didn't want to change it). (As a quick addendum, if we're writing a test with TDD in mind, then something is happening inside GetCity() that has a significant amount of logic going on. Thinking about the test as being to a contract helps us to separate the intention from the implementation - the test will stay valid no matter what we change behind the interface!)
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POIs there a way to protect Unit test names that follows MethodName_Condition_ExpectedBehaviour pattern against refactoring?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USsimple
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.