There are other libraries than Moq. Nsubstitute, FakeItEasy, etc.
With Moq and most mocking libraries, you generally just need to make a method virtual for mocking concrete classes.
Most mocking libraries use Castle Project's Dynamic Proxy, so they should be able to inject things without the need of interfaces. Interfaces for everything comes from the .net community's obsession with patterns, abstraction, clean architecture, and DDD.
You can use vscode with file based projects. With Rider/Visual Studio you can show hidden folder so long as they are in a folder or subfolder of a project.
Otherwise, you'll need to add a solution folder and items to the solution folder.
Right, marking methods as virtual is the other route I saw. Are most C# codebases opting to do that rather than add interfaces? It feels weird to edit signatures like that for testability, but maybe it's just what I'm used to - I'm putting all of my objects in constructors already for testability's sake, and I'm no stranger to making a factory or two.
VSCode has been my way forward for file-based editing so far. It's not so bad - just feels like I'm doing things that I ought not to be when I'm searching for DLLs or a random "scripts" folder in the root folder of our repo in Rider. In IntelliJ IDEA, all of the folders are just sitting there, ready for quick edits.
I think C# overcommitted on interface-driven design. It's good in some instances, but the more I work in code the more I think that the majority of it is needless and oftentimes harmful to maintaining a healthy code base.
Thanks for the pointers! Nsubstitute looks cleaner than Moq at first glance.
That is a good question. I'm not sure. I've seen a lot interface usage for testing web apps or backend services at companies when I was doing consulting work.
I personally use stubs for higher reuse, favor integration/functional tests over units, and InternalsVisibleToAttribute to allow the use of internal classes / methods from test assemblies. Its been a long while since I reached for a mocking library. I probably use structs, statics, and extension methods more than the typical dotnet dev. And for DI, I have no qualms just using concrete classes or base classes.
I also built my own extensions to xunit to enable DI in test methods, since I do more integration tests.
Extension methods for interfaces can be very powerful along with the newer default interface feature. So using that where it makes sense, I get.
In dotnet itself, interfaces are only heavily used for key extension points, so you see them more enforcing specific idioms like IComparable<T>, IReadOnlyList<T> or adapter/extensions for System.Data.x, Microsoft.Extensions.x, and Asp.net core MVC. For the adapter types of things there is generally a base class that implements key interfaces and you can create stubs or mocks from those.
For the files... for stuff in the root folder like .editorconfig, gitignore, etc. I generally create a virtual Solution folder and add those files to it.
For folders with larger amounts of files, I sometimes create an empty project or use specialized project for it like node or powershell project which can be installed as VS extensions, especially if its for a project where the team lives in Visual Studio.
That said, I do most of my coding in JetBrains rider or vscode these days and keep a terminal open. When I'm on a windows box, I have nano and neovim installed, so I can just quickly edit scripts that way or just do code /path/to/file as needed.
Really liking your approaches and wish our code base followed them more as well.
Mocking leads to “interfaces everywhere”, I agree. The latter also results from the attitude of putting interfaces all over, even if there’s just a single concrete implementation that makes sense at any point in time, like a file hashing routine (which of course should just be a function but that’s not a thing in C#). Dependency inversion gone overboard?
My biggest qualm with mocking is setting up a detailed test, where every method called is specified, alongside their order etc. You’re reimplementing the entire method essentially. Those tests I despise.
The best way IMHO is to start simple and then add abstractions and interfaces over time. That will mean that, yes, when you come in to a project late there will be lots of those...
There are other practical reasons for using interfaces other than just "patterns" and "testing" though. Perf is one; you can avoid a lot of unnecessary mapping by being able to pass concrete types between modules when the receiver is accepting a shape instead of a concrete type...
Yes, we're quite familiar with SOC guidelines. We will be including all of Security, Confidentiality, Privacy, Availability, and Processing integrity categories into the SOC 2 examination. I think, given that Infisical is a secret-manager, all of these are very important!
Currently, we only support Mongo, although we received requests for some other ones. Which one are you interested in?
Almost any other standard database would be a better choice: Postgres, MySQL, even Redis.
Most companies avoid using MongoDb and lack the staff needed to administer it properly. It’s also hard to find a managed solution for Mongo in most cloud providers.
- "No trackers, no javascript, no stylesheets"
- inline js.
- inline stylesheets.
- uses favicon which can be used for tracking.
- not self hosted.
- requires an account to sign up
- "TOS" > "Bear may disclose personally identifiable information under special circumstances, such as to comply with subpoenas or when your actions violate the Terms of Service."
- can't be bothered to indent the html.
- payment system could require real identity.
I suspect what he means is "this is a safe space" in contrast to the open/hostile internet "out there", i.e. there is no nefarious intent. As you point out, this is really mostly virtue signalling (and probably well-meant). The fact that actually there is JS, there are trackable signals, your PII can and will be disclosed etc is sorta beside the point of sites like this.
If an organization or person is selling a product focused on privacy and there is a TOS that focuses on the org or person avoiding liability but lacks documentation or links to resources to help users to lower their liability and increase privacy, its a red flag to me.
Their servers are located in the Netherlands. Its good that they list that. It would be better to hoist information into something that is less policy/legal oriented and perhaps provide an overview of the laws of that region.
Other things that should be listed is how is the data stored, transferred, how is it protected, are there any steps to anonymize the data, hash the data, or provide a way to bring your on key for data encryption.
Is there any telemetry gathered or stored by the server? Is the code in the github project the same that is deployed in production or is there a private repo that augments the code?
Fyi, HN uses a limited version of markdown which doesn’t recognize standard markdown list syntax. If you want to make a bullet list, you have to put blank lines between each bullet point, like this:
——
- "No trackers, no javascript, no stylesheets"
- inline js.
- inline stylesheets.
- uses favicon which can be used for tracking.
- not self hosted.
- requires an account to sign up
- "TOS" > "Bear may disclose personally identifiable information under special circumstances, such as to comply with subpoenas or when your actions violate the Terms of Service."
Please don’t say HN uses any form of Markdown. It’s its own thing entirely with absolutely no foundation in Markdown—the only points of any similarity between Markdown and HN comment formatting predate both by multiple decades. HN’s formatting gives you paragraph breaks (by blank lines), linkification (with no delimiter, unlike stock Markdown which requires angle brackets, to the surprise of many), monospaced blocks (by two space indentation), italics (with asterisk delimiter), backslash escaping for asterisks, and that’s all. Every element of this, or a very slight variant, has been common in lightweight markdown languages since before Markdown, and all but the backslash escaping and hyperlinks (which hadn’t been invented yet!) have been in conventional use in communication since well before the web (and match some typewriter conventions from before the invention of computers).
Markdown is not the only game in town. Yes, for now it’s the dominant lightweight markup language (more’s the pity—it’s a right mess, thoroughly unsound and inconsistent in a great many ways), but a lot of stuff exists beyond its horizons; it’s only an instance of LMLs, not the whole class.
Most mass shooters come from single parent households or dysfunctional family homes. U.S families vary and many don't live near other family members where they can get help and American communities are not like other cultures or countries where they are involved in raising children.
So if a child's immediate family has issues, there isn't an alternative for that child to to go to to help or for a positive role model. And there are very few public positive role models.
The U.S. has the highest number of single parent households of any country. It also has some of the higher number of mental illnesses and lower numbers of mental health workers.
U.S. works longer hours, have less vacation and holidays, so children are left to their own devices more. Our food supply is laden with chemicals that are not allowed in other countries thanks to lobbying and the FDA. (I'd be interested to see how that impacts mental and physical health).
Our public schools are full of physical, emotional and sexual abuse. The latter being higher than Catholic churches and not very well reported on by any media.
Couple that with media addiction (old,new, and social) and the phenomenon of media "contagion" where you get mass shootings in clusters due to media coverage and you have a recipe for disaster.
Given the failure of the war on drugs, prohibition and the context above, not sure how gun control or confiscation would work when Americans tend to work around those kind of things. Even without guns, we now have drones so its only a matter of time before someone uses those.
However, all that generally gets talked about is either gun control or more guns e.g. arming teachers rather than the underlying causes. Kids used to bring guns to schools without incidents for decades until the 90s when you started to have many latch key kids coming of age from homes where parents were never around.
.NET 6 LTS
.NET 7
.NET 8 LTS
FreeBSD support has been in the works for a while:
- https://wiki.freebsd.org/.NET
- https://github.com/dotnet/runtime/issues/14537