203

Reluctance to modify code for the sake of testing shows that a developer hasn't understood the role of tests, and by implication, their own role in the organization. The software business revolves around delivering a code base that creates business value. We have found, through long and bitter experience, that we cannot create such code bases of nontrivial ...


111

Checking for uniqueness and then setting is an antipattern; it can always happen that the ID is inserted concurrently between checking time and writing time. Databases are equipped to deal with this problem through mechanisms like constraints and transactions; most programming languages aren't. Therefore, if you value data consistency, leave it to the expert ...


75

It's not as simple as you might think. Let's break it down. Writing unit tests is definitely a good thing. BUT! Any change to your code can introduce a bug. So changing the code without a good business reason is not a good idea. Your 'very thin' webapi doesn't seem like the greatest case for unit testing. Changing code and tests at the same time is a bad ...


38

I think what you call “fail fast” and what I call it is not the same. Telling the database to make a change and handling the failure, that is fast. Your way is complicated, slow and not particularly reliable. That technique of yours is not fail fast, it is “preflighting”. There are sometimes good reasons, but not when you use a database.


20

.NET Framework is a VM, a JIT compiler, an object memory system consisting of a memory allocator and a garbage collector, a loader, a linker, and a runtime system (collectively called the Common Language Runtime (CLR)) which executes and supports a language called Microsoft Intermediate Language (MSIL). It is also a class library called the Base Class ...


18

Designing code to be inherently testable is not a code smell; on the contrary, it is the sign of a good design. There are several well-known and widely-used design patterns based on this (e.g., Model-View-Presenter) that offer easy (easier) testing as a big advantage. So, if you need to write an interface for your concrete class in order to more easily test ...


15

This started as a comment but grew too large. No, as the other answers have stated, this pattern should not be used.* When dealing with systems that use asynchronous components, there will always be a race condition where the database (or file system, or other async system) may change between the check and the change. A check of this type is simply not a ...


13

It is IMHO very simple to understand that for creating unit tests, the code to be tested must have at least certain properties. For example, if the code does not consist of individual units which can be tested in isolation, the word "unit testing" does not even start to make sense. If the code does not have these properties, it must be changed first, that is ...


11

I take issue with the (unsubstantiated) assertion you make: to unit test the Web API service we will need to mock this factory That's not necessarily true. There are lots of ways to write tests, and there are ways to write unit tests that don't involve mocks. More importantly, there are other kinds of tests, such as functional or integration tests. Many ...


9

You are in luck as this is a new project. I've found that Test Driven Design works very well for writing good code (which is why we do it in the first place). By figuring out up front how to invoke a given piece of code with realistic input data, and then get realistic output data which you can check is as intended, you do the API design very early in the ...


8

HTTP doesn't work like that. The client sends a request, then the server sends a response back. No other communication occurs. Well, the server can send 1xx informational responses before the main response. But there is no way for the client to send updates about a sent request. (The situation is very different for HTTP/2 which can multiplex multiple ...


8

If you need to modify to the code, that is the code smell. From personal experience, if my code is difficult to write tests for, it's bad code. It's not bad code because it doesn't run or work as designed, it's bad because I can't quickly understand why it is working. If I encounter a bug, I know it's going to be a long painful job to fix it. The code is ...


7

The purpose of verifying the email address is to obtain proof that the owner of the email address and the user who registered are the same person. It therefore follows, that the logical thing to do if an email address remains unverified for a significant length of time, that the user who registered is not actually the owner of that account, or you have ...


6

Your question talks about repositories being IQueryable (i.e. classes implementing the IQueryable interface), whereas your linked resource talks about repositories returning IQueryable objects. That's not the same thing. For the purpose of this answer, I'm going to assume you misspoke and meant to focus on repositories returning IQueryable objects. ...


5

In my view there is rarely a good case for a shared project. The main reason is versioning and change control. If you recompile source code, then strictly speaking you have a new version. Its not so much of an issue in these days of build servers and ci. But some of us will remember when building on a devs machine and copying to production was a normal ...


5

I suggest you to read a great book about the C# dependency injection by Mark Seemann, with a lot of real world samples for different tasks you can do with it, even with circular dependencies similar to your case. In general, the main design rule is You can't resolve the problem on its level, and in this case it's true too. You really need a mediator here to ...


5

Yes .Net Core although still very new, is suitable for rapid web development. Caveat #1 : Asp.Net MVC/WebApi is the more mature technology. You may find it more compatible if you are doing lower level type operations. Caveat #2 : You are always faster programming in the way you know. It sounds to me like you were making too big a jump on a project with ...


5

When dealing with style, it is always more useful to take either an official style if one exists, or to use the one commonly adopted by the community of developers writing in a specific language. You're lucky, for C#, there is an official style created by Microsoft. Another good thing is that Microsoft also developed a tool called StyleCop which checks if ...


5

Extension methods are just syntactic sugar for ordinary static method calls. Extension methods make possible the ability to "spot-weld" methods onto existing types, without requiring inheritance, composition, weaving or any other language mechanisms. But they're just a proxy for an ordinary method call; they don't participate in the design of the class, ...


4

Are there any other objections? Are there any legitimate, real-world reasons why DI with a static/global service locator would be bad? Ugh, yes. Statics/globals are horrible. They assume that the runtime of your application is homogenous - all of your instances require all the same sort of instances all over. That is naive. They interfere with concurrency,...


4

No problem at all, in fact i would suggest approaching the problem the other way round. Authenticate all your actions by default, and use AllowAnonymous to permit access to your public actions. If you're worried about missing some you can use unit tests or static analysis to flag up unprotected actions.


4

This kind of depends on where and how you expect this application to be deployed. If you control the deployment or can make rules (such as in the form of a "maintenance guide") that those who operate the application must follow, then this is perfectly OK. There are a lot more aspects to this that you might want to consider: Could there be a requirement ...


4

To give you a direct answer to Is it bad practice to assume that server side file will never be deleted by external forces It is not bad practice to assume it is unlikely a file will never be deleted (in case it is, which we cannot tell you, this depends on tons of details of the particular case). However, you always need to implement some error ...


4

How would you determine the importance? The simplest way of ordering the usings is the to apply an alphabetical order; However, it is often useful the make the difference between usings pointing to the .NET Library and your own namespaces: using Microsoft.AspNetCore.Mvc; using Microsoft.AspNetCore.Mvc.Rendering; using Microsoft.EntityFrameworkCore; using ...


4

The ASP.Net core docs recommend it Each services.Add{SERVICE_NAME} extension method adds (and potentially configures) services. For example, services.AddMvc() adds the services Razor Pages and MVC require. We recommended that apps follow this convention. Place extension methods in the Microsoft.Extensions.DependencyInjection namespace to ...


4

I would argue that writing code that cannot be unit tested is a code smell. In general, if your code cannot be unit tested, then it is not modular, which makes it difficult to understand, maintain, or enhance. Maybe if the code is glue code that really only makes sense in terms of integration testing you can substitute integration testing for unit testing, ...


4

I have zero experience with .Net Core, but I am working at an application where we have wrapped localizable strings by using their English pendants as a reference index. This is quite comparable to the technique described in the question. The idea here is to avoid usage of Localizer["foil"], but instead using larger phrases like Localizer["wrapped in foil"]...


4

The goal of extension methods is specifically to be able to extend either classes of other assemblies or interfaces. The recommendation to use them sparingly is right, for several reasons: Extension methods, when used too much, are polluting IntelliSense. This could be extremely annoying when (1) the extension methods were created in a core namespace which ...


4

Pagination is not a domain concern. The domain layer typically does not care to know the number of records fetched from a persistence store. It is a performance concern, specifically on the database side. And the only domain elements that deal with the database are repositories. So the way I see it, you need a mechanism to send it from the API request (or ...


4

Here are some suggestions: keep the solutions in one repository. That is probably a no-brainer, since it does not enforce a specific project/solution structure. share common logic - well, simply create shared libaries. Note you do not have to put all your applications into one large solution for this, you can simply share the same C# project in different ...


Only top voted, non community-wiki answers of a minimum length are eligible