New answers tagged

6

I think you know the answer to this question already: No, it's not great to run different code in test and production. This increases the risk when you move to production. However, it's better to run different code in test and production than to not test stuff. In the specific example you've given of permissions, it sounds like you should really be working ...


0

public string GetValueA(){ string a = service1.GetA(); return Format(a); } private Format(string unformatted){ return unformatted.ReplaceSpace().PaddingZero() // for example " 123" will be "00123" } This looks to me like a parser - we're taking some general purpose representation of a message from service1 and ...


-2

Basic mode: Test all of the public methods on everything. Advanced mode: Test the application, or top most level of your code. Other tests are optional


2

Your code looks fine. I'll assume .ReplaceSpace() and .PaddingZero() are extensions methods that have their own unit tests. This is exactly what extension methods are for, simple behaviour that has no side effects. If the formatting is specific to this service and the result is not parsed by another service in your domain, a private method is good enough. ...


1

I generally try and isolate the "interesting" stuff from the "boring" stuff and focus on testing the interesting stuff. In your example (without any additional context), Format seems like the interesting stuff so it makes sense to pull out the Formatter and test that separately. Testing it through GetValueA and GetValueB means you will ...


5

I've seen a with prefix used in a couple of different ways that may be similar to what's being done in the codebase you're working on. Joshua Bloch's Builder pattern var myobj = MyObj.builder() .withProperty1("property 1 value") .withProperty2("property 2 value") .build(); Clone immutable objects var ...


3

The straw that breaks the camel's back Very simply put, the extra effort you're talking about is a straw. The camel does not care about dealing with the added straw, so that's all fine. But by reapplying this "another straw makes no difference", eventually the camel's back will break. And it's not the final straw's fault. It's the fault of all of ...


2

There's less code to read through when you read the utility method. But there's more effort when reading through the callers of the utility method; the reader now has to understand why there are several versions of check_eligibility() and which one to call under what circumstances. In general, it is a bad idea to offer multiple versions of a function that ...


1

I agree with mtj's answer that the user's have no vested interest in jumping through hoops for your internal data's sake. However, I don't quite agree that that means you can't merge your databases. To summarize the below detailed explanation, the trick is to favor the user experience, and avoid needless spam or requests for action. Instead, the systems ...


4

Great, more email for the spam folder... OK seriously now: your business' desire to merge the user accounts is not of concern for the customer. Therefore, the customer will not have any desire for your emailing them not have any interest in clicking your link eventually not even be an active customer any more who places any value on the account he has not ...


0

Why do you need to force B's users to reset their passwords? You could copy the hashed passwords from B to A. That said, if A and B use different hashing algorithms, you would need to modify the login process on A to handle that. Be aware that some people will not click on links in unsolicited emails. Give them an alternative.


Top 50 recent answers are included