Bognar posted:

I don't really like using the Seed method since it is run after every update-database. It's a bit easier to get things wrong than just having your SQL run once, guaranteed.

Bognar posted:

If I'm making significant custom changes in migrations, I like to make a new blank migration and add my custom SQL to that rather than adding it to one with all the auto-generated code. It's just an organizational thing, though.

Also, if you're doing custom migration code, it may be tempting to instantiate a DbContext to do your work. Don't do this - all your migration code should be in SQL.

The Wizard of Poz posted:

I've been thinking about unit testing a lot lately, and one of my points of confusion with the whole process is how to properly test something like an MVC controller. Since the controller itself will usually do very little, what you really want to test is whether it makes the correct calls to the correct methods in its dependant classes. For example:

code:

public class EmployeeController : Controller
{
    
    private readonly IService<Employee> employeeService;
    
    public EmployeeController(IService<Employee> employeeService)
    {
        this.employeeService = employeeService;
    }

    public ActionResult Details(int employeeId)
    {
        var employee = employeeService.GetById(employeeId);
        
        return View(employee);
    }

}

The action in this controller (Details), has only a couple of things to test:

1. That the IService<Employee>.GetById(int id) method gets called
   
2. That the correct view is requested
   
3. That the view has been sent some data
   

I figure that the other stuff one might be tempted to test here is actually not the controller's responsibility and can be ignored. For example, testing that the correct client is sent to the view is pointless because that's really a test of the service layer, not the controller action.

So my question is - how do I test point 1? Or rather what is the correct way to test point 1? I imagine I could mock up the employee service with a fake "GetById" method that simply sets a flag saying it was called, and then the test can run an Assert on this flag. But this doesn't seem right, putting logic like that into a mock object. I can see this is probably a very common problem so I imagine there's a widely accepted solution?

Ithaqua posted:

No, you're right. Most mocking frameworks let you assert that a mock method was called.

uXs posted:

NSubstitute!

RICHUNCLEPENNYBAGS posted:

In my personal opinion there's not really much value in a test like that. I mean I guess it's an unpopular one but I think it's just crap to maintain that won't give you that much insight into anything.

Gul Banana posted:

Ithaqua posted:

Dumlefudge posted:

This is a more general question than something specifically regarding .NET development, but... as someone who isn't well-versed in testing (aside from a bit that was done as part of my degree), can I ask how you would go about testing something like what The Wizard Of Poz posted? Any bit of insight in how to identify how to test things would be great, although I get the feeling that the response may boil down to "It depends on the specifications".

Being a recent graduate who can see that the code is obviously in need of work, but without really being able to see how to improve it, is a bit demoralizing.

crashdome posted:

More often than any other bug I inadvertently create (while not having any unit tests) is because I didn't update a related class or interface properly when adding a new feature somewhere and I get the dreaded null reference exception. Nothing I hate more than to see something that worked prior suddenly just bail somewhere N-levels deep into the logic 5 seconds into hitting "Debug" and having to dig out why with a dozen different line breaks and mashing "Continue" until I find the culprit.

AuxPriest posted:

Alternatively, set a breakpoint at the beginning of the suspect block and step through with f10 until you find the offending line. When you do, step into it with f11 and start digging.

MachinTrucChose posted:

Can I get some advice from more experienced Windows devs? I'd like to have a desktop app that can search a specific directory for files, using filename as well as file contents (then I do something with the result the user selects). The target directory is on a network drive, and the files are a mix of text, XML, and Office files.

AuxPriest posted:

Alternatively, set a breakpoint at the beginning of the suspect block and step through with f10 until you find the offending line. When you do, step into it with f11 and start digging.

SirViver posted:

Alternatively, you open Debug > Exceptions and check "Thrown" for Common Language Runtime Exceptions (or, if necessary, just for the exact exception type if your code legitimately throws/handles other exceptions) and hey presto, VS will break right at the point where the exception is generated.

RICHUNCLEPENNYBAGS posted:

What do people use to enforce indentation and code style and the rest of that kind of stuff? We're using a shared ReSharper file but it's kinda so-so (some of the settings do not seem to be getting shared consistently; don't know why) so I wonder if there's a better way to do it. (Ideally you could just point it at files and say "make them conform to the style").

Ithaqua posted:

Code reviews, FxCop/StyleCop analysis rules as part of CI. Basically, make it a pain in the rear end for the developer not conforming to rules.

Drastic Actions posted:

My last job had this, and it worked out really well. It was a royal pain in the rear end, but the end result was worth it. Especially after getting resharper and matching its rules to our FxCop/Stylecop set.

RICHUNCLEPENNYBAGS posted:

There are different theories about testing. My personal opinion about test-driven development is it's like a religion in that devotees push it hard on people but none of them can really fully adhere to it and feel guilty about it.

What I like to test is, you know, basically that procedures have the expected results. Particularly if there's some high risk to getting it wrong (for instance, Stack Exchange does very little testing, but everything touching finances is heavily tested, according to them). Tests are also useful if you want to refactor or add capabilities to some existing code but want to verify that you haven't changed the old behavior. Or if you identify a bug and want to ensure you've fixed it.

This is totally different than the normal TDD stuff, I guess, but I also use some reflection-based tests to verify the validity of my dependency injection configurations, Entity Framework classes/contexts, and so on.

crashdome posted:

When I use unit tests, I rely on them and they help me. When I force myself to write unit tests for things that are unimportant, I waste my time. TDD for me is just not feasible because it literally doubles my development time. I DON'T need to unit test controllers/services if most of the methods I'm testing are only used once somewhere. Good exception handling will pinpoint a problem quickly during integration testing or even in live production if it's just that rare of a circumstance. I DO need to unit test that recursive method, factory methods, or that class that performs fragile operations.

More often than any other bug I inadvertently create (while not having any unit tests) is because I didn't update a related class or interface properly when adding a new feature somewhere and I get the dreaded null reference exception. Nothing I hate more than to see something that worked prior suddenly just bail somewhere N-levels deep into the logic 5 seconds into hitting "Debug" and having to dig out why with a dozen different line breaks and mashing "Continue" until I find the culprit.

Now integration testing... that is something I really wish I could have a clone of myself to focus 100% on. Most of my bugs are now things like UI oddities or when some device in my IO stack decides to stop working correctly mid-process and my application shits itself. It's not purely my fault but, the users always want "my application" to handle everyone else's problems.

Dumlefudge posted:

Being the newbie, I reckon that there's a high risk of "getting it wrong" everywhere.

Ithaqua posted:

Code reviews, FxCop/StyleCop analysis rules as part of CI. Basically, make it a pain in the rear end for the developer not conforming to rules.

Boz0r posted:

Is there ever any reason to do custom setters like this, when not calling any external listeners or anything(programming in Unity:

code:

public string Name
{
    get { return this.name; }
    set
    {
        if (value != name)
        {
            name = value;
        }
    }
}

Boz0r posted:

Is there ever any reason to do custom setters like this, when not calling any external listeners or anything(programming in Unity:

code:

public string Name
{
    get { return this.name; }
    set
    {
        if (value != name)
        {
            name = value;
        }
    }
}

LOOK I AM A TURTLE posted:

If it's intended as an optimization it will actually have the opposite effect, since comparing two strings is far slower than assigning a string value that's already there to a property. In fact, assigning the same string value to a property could conceivably end up being optimized away entirely through some combination of string interning and the JIT compiler. (It probably won't, but don't sweat it.)

If it's intended as something else than an optimization it's merely pointless, unless something else is also happening inside the if-block.