IMPORTANT INFO: You're NOT supposed to write the attribute with the file path/line/column yourself. You're supposed to use a source generator to implement the interceptor for you. The source generator runs whenever anything changes un the source code, so it will update the location(s) if the interceptons. If you use source generators as you're supposed to, changing the code will not break it.

The one problem I see with this is that its going to be confusing to people who aren't expecting interceptions. For example, when mocking, you pass a stub into the constructor of the type you want to mock and thus its very clear why you get a certain result from a method call. In this case, your object is null yet you don't get expected behaviour when calling members on null. I guess you can step into the method call to figure out what's going on but it feels "wrong". Maybe they can add some tooling into the debugger to make this less weird? Also, what happens if two interceptors are registered for the same invocation? I assume the last registered interception is the one that executes. This would also lead to weird behaviour where I think tooling is necessary to make it obvious.

Mocks are overused, agreed. But I would much rather still use an interface and have a reusable fake in-memory implementation instead. This reduces the amount of setup code and performs better and is easier to understand. One potential danger is if the fake implementation and the real implementation differ, but mocks or interceptors can be just as bad in this regard.

Aren't you advertising the wrong tool for an already solved problem?

I absolutely deeply hate this feature. It is way too magic, and I can see all the ways it will be abused to create unreadable and confusing code. Dependency injection and mocking has worked fine so far, I don't see how this solves anything.

While an interesting feature, and definitely one that'll be used in C# 12, the use of an interface is the proper approach here; there''s so much setup and magic happening, that the traditional and well known interface abstration/mocking approach comes across as simple and straight forward.

I really like the idea. One way to solve it would be that alongside each interceptor is a public static Func (public static Func null) for the first test and mocker.SetupGetBySlug(slug => new Movie() {...}) for the second. On dispose the mocker clears the Funs so that the interceptors call the original method.

this interceptors are fishy. I thik when they come up they will lead to very bad spaghetti like projects where a lot of thinks happen like magic. c# is static compiled language so you can refactore anything you want with easy and you do not have to worry that something breaks. adding interface should not be problem in legacy code.

6:41 THIS is a pretty good easter egg =)

I'm just not seeing the value, at least not yet. Let's say the interceptors will be source generated and the usage will be simple. Still, I'd rather mock using Moq or Nsubstitute and setup the mocked methods within the test (if they need to differ between tests) than have a separate interceptor class with the mocking logic. It may just be too much magic for my taste. But I do agree that this could benefit people working on legacy codebases. One problem though, how do you use this new feature on a legacy project unless you migrate it to .NET 8?

Dear @nickchapsas, if you think that interfaces are most abused feature in C# (or it is for the fact your biggest problem), I totally envy you. Please, hire me for such projects! I would love to have these kinds of problems. What I see on not-just-legacy codebases is that developers with 10+ years of experience in C# does not even know how DI works, or how to use interfaces generally. IMHO: A feature with the highest abusing factor in C# are exceptions - they are just used as `goto`s.

the Doug flash when you said "THIS" made me laugh like crazy!

This pretty much replaces one headache with another headache. :)

You can 'mock' statics. Just point your actual static property/method to an updateable static method and then set this method to what you need for testing. Done this for years for dates and principals. No need to pollute your class/constructor with bloat interfaces.

Still fail to see the point in mocking database interactions. 99/100 the reason your code will fail is the database. Yet we write unit tests that eliminate the database from testing. I get the example, but it should be pointed out, that if your unit tests don't test your database, then you're still not (really) testing.

While I do with the premise (abuse of interfaces) I disagree with the interception to add "domain" functionality. Does somebody remember/used PostSharp? The main problem with interception is you are adding "sorcery" that is not obvious unless you explicitly point it out. In my case, I am moving towards only using interfaces just for IO and branching away from things like repositories.

It looks like we kind of reinvented Shims from MS Fakes... Been there, don't go there ;) But to get to details - we need to change a built to make those tests working. You probably don't want to affect production builds, so there are two options: 1. Build two dlls, one for tests another for running(like MyLib.dll and MyLib.Testable.dll) plus some magic to switch them in tests 2. Add interceptors to Debug built, but not to release Then, we want one interception to handle multiple tests, so we intercept all calls and framework decides what mock code to run. At first glance it's doable if we run one test at time, otherwise hard to determine (especially if we intercept statics) The question is how deep dependencies should we intercept. If we test A, it uses B and B uses C and we want to intercept usage of C should we intercept calls inside B even though we are testing A? And what if B is in another project? And what if it's in nuget package? Are we expecting to see packages like *.Testable? (Just like we have Analyser packages for many nugets). I guess paackages should still use interfaces if it is useful for testing All in all, could be nice feature for legacy code bases, but when developing a testable solution, I'd not choose this as preferred way for testing

I doubt this will change the way majority of people are writing tests and code. TypeMock and MS Fakes are there for very long time, allow for mocking pretty much anything without interfaces (by doing IL rewrites) but aren't that popular. Probably because of pricing, but even across big corporations which pay for VS Ultimate or have budget for TypeMock you still rarely see them used. And there are free, open source libraries with similar capabilities. So yeah, if you didn't want to write interfaces just for testing, you could do it even now and interceptors aren't going to change it.

I wonder how many people remember Pex and Moles which allowed mocking of things which did not have interfaces. I also believe the product Typemock will also do the same but I've never tried it.

The interceptor feature sounds a bit dangerous, but I'm open minded and interested in seeing how the feature develops. However, we can even now use tools such as passing delegates and using classes with virtual methods to create testable code :)

I'm afraid I don't see it. The flexibility you have with a framework like moq would be very hard to achieve. You have to have the code for all possible uses of a method in the object you want to mock on a single interceptor, how are you going to know what are you mocking it for? If you could define one interceptor per test I could see it working, but that's not how that feature is going to work. Maybe with AsyncLocal you could pass some info or where this is coming from but, honestly, I don't even want to imagine the complexity of writing such a source generator, if it is at all possible.

This will be a real life saver for my legacy C# 12 apps 😬

I made it as far as providing the line number and character location before deciding this is worse than mocking.

I am a strong advocate of testing the binary that will be deployed, not code that is 'different' through weaving. The most pragmatic way forward is having integration tests of the public API/interfaces. Internal classes, DTOs etc. count towards the code coverage of the integration tests. Unit testing every single class, every single class being mockable/having an interface is a pain with refactoring.

If it requires a static path that will never change, that's already a failure point. I have yet to meet a team of developers that use the exact same pathing across their systems to store their code. On top of that, Line and column definition seems incredibly clunky and prone to breaking.

Love it. There's a reason I don't want to use interfaces everywhere: it implies my code is ready for all sorts of implementations passed in, for everything I want to test. It's not. That's lots more work.

There's also another problem with your code: if you actually run it, the interceptors will still be called instead of the actual code...

I would not go this route, but I do wish C# had a good level of AOP support like Java.

One thing i dont understand, how ill you create an interceptor for a method that needs to return something different between tests? In your example you comment out the previous code. But now the previous test would break. Can you have multiple interceptors for the same line?

This is the wrong way in my opinion, we should have like special operator called, for example, "interfaceof", so we can extract an interface of a class if it covers all non-static public properties/method. It's cleaner, simpler, less verbose and the most important: intuitive. That would not only simplify mocking of our own services, but most importantly we will be able to abstract from third party services which authors didn't thought about exposing interfaces (today we need some libraries that do assembly magic at runtime).

As long as we don't have to write the interceptors ourselves, hey why not. This would actually be useful in a legacy project I am currently working on. There's a lot of untestable stuff and transforming the codebase is just not feasable anymore at this point.

I used to work on a legacy solution (comprising 90 projects, mind you!) that had been created with no unit tests and no interfaces. There was an integration tests base class, but it was a little hell to deal with and introducing unit tests was a lost cause. Even my senior colleague with 15 years experience gave up on it. Being able to introduce unit tests for that project would be a life-changer for my ex-colleagues.

This is going to need a much better way to target the function call than specifying the file path (not guaranteed to be the same across developer machines) and line numbers and character offsets (likely to change when the target file is modified). This is far too unpolished a solution for me to get excited about or recommend to my teammates.

i think the best use case for this will be when wanting to have different types of builds. where u could write a separate interceptor for different clients and compile a version for each of these clients per interceptor class. Some questions i have are, do interceptors have conditional options? like if its Tuesday don't intercept or something random like that

Unfortunately I don't agree with using interceptors. Various other people in the comment section pointed out major drawbacks. I want to add that testing like this hampers find all references(the unit tests using the code) during minor refactoring, makes it difficult to do unit test code coverage reports. Also how is quality control software like SonarQube going to deal with this?

Oh please God, don’t tell me that Nick is jumping on the interceptor train

You suggested removing the interface from the one thing that actually makes sense to be behind an interface. And instead completely missed out on the fact that those IValidators should be the ones to rip out of the code. Validation should just be a pure function and shouldnt be hidden behind an interface?

interesting feature, going to check interceptors out soon, thanks!

Mock frameworks still have a lot more functionality, just for example, verify.

When I heard of the new interceptors feature, this was my first thought as well - "will be great for testing". Previously, the only way to mock or stub out something that was either non virtual or static was to use Microsoft Fakes (using Shims) but that's only available to VS Enterprise users. (There are some other alternatives, but nothing free as far as I can tell). This will certainly change the way we do testing, win win.

Just use interfaces to mock IO abstractions. Use classes if you need to keep track of changes during the lifetime of the object and use statics methods in any other case.

I feel in this scenario it's a really roundabout and magical way of replacing a function at runtime. This is done in other languages, and so perhaps the warts of doing that translate well over to this novel method.

I'm really not convinced by this interceptor. Also, I'm not a fan of moving code from one file to another to do almost the same thing. I prefer to centralize my test and the "Arrange" part (setup) in the same place than to separate everything.

Change or add one line to tested class and references by column and row number will fail. THis could be useful only if tested class will not be modified in the future.

Sound like a monkey patching

As long as it doesn't become a crutch that enables bad design rather than going with TDD to help enable maintainable codebases. It seems like this could be abused (so can interfaces and mocks) if we're still thinking about testing _after_ writing the code like in the example in the video. I worry about long term maintenance and complexity. I definitely see applicability for third party classes that do not expose an interface/abstraction for easy testability; we should still use this in addition to still using interfaces where interfaces are actually more appropriate. In other words, still no silver bullet.

THIS contains an excellent Doug DeMuro reference 😄

This could be really useful when working with some old code which because of its complexity cannot be easily refactored

felices san fermines mi gente

the doug demuro thing was gold lmao

In corporate world it would be beneficial to have possibility to mock static classes and methods. This is because of "quality gates" which require certain level of code coverage. Because of this people are avoiding static classes. But these interceptors will not help. They require to give exact location in code which should be intercepted. The problem is that different test environments require different path.

Nick you said the purpose of these is AOT. Now I'm normally all about doing things at compile time, but i just dont see why tests need to be AOT compiled, when you really just want to run tests quickly to get feedback. Why not stick to reflection or find a way to source generate the implementation to an interface rather than additionally needing to statically analyze every call a class will take from one of the test methods, just to get those line/column numbers...

As I understand, only one interceptor may point to the same file,line,char… having two would give you a compile error… Another problem I see here is that the interceptor will always be overruling the method and thus it will affect the actual binary… so whenever the method is called it will return null!

I love interceptors. I understand many people's worries, but I think it's generally overblown. IDEs will, similar to implicit conversions, give you intellisense whenever they're intercepted.

Hmm... What about if the thing that you are intercepting supposed to return different thing on a different test?

Probably the first time that I not agree your approach. It’s weird. The tracking of mock is a phantom in the code. :/

are you saying this stuff works only on source code, if the attribute needs the path to the file and the position, because that would be quite a limitation

This is like using a rocket launcher to kill a mosquito. A better example I think is to use of Func or Actionn to inject behaviour, that can be a better alternative than passing in interfaces.

Looks great in terms of testing the code where is used third party library or testing legacy code. This feature may be helpful

I am really excited!!

I expect rider, visual studio, or Roslyn will probably get a validator for if these are mapping correctly, especially if an agreed upon nomenclature arises

You can of course mock classes, assuming the methods you want to mock are marked virtual. Perhaps better than making a god damn interface for every god damn class. :)

well, I am not sure we should be chaning anything in the main project. and this is not much different to mocking as the mock libraries does this behind the scenes using similar concepts to interception like proxies, etc. But I agree with not requiring interfaces all over the place. this is what TDD/component tests encourage, the contract we really care about is the one the system has with the external players, like API callers, Queues, DBs, downstream services, files, logs, etc. internally it does not matter if we have interfaces are not, thinking this ways will make the so called "unit tests" obsolete, the high-level tests with the TestWebApplicationFactory is all we need, then we can have an in-memory represntation of those external players using mocks or fake implementations, it does not matter as long as we are only intercepting in the tests and only the external points of the system

That Doug DeMuro reference though :D

This looks like event-driven testing capabilities. The process of testing emits event and other part of code intercept event and handle it.

Yeah, i may be an outcast for my opinion but there are a few guides i have for tests. when they are more complicated then your code they are making things worse. they would need a test for the test! A test should really test something and not just hit mocks. testing crud without any validators in it, is just testing if your database works but then without using a database? you test nothing! But if you do have a validator you have a good case to write a test, make sure in your design that you can call that validator without using mocks, a validator should need no database, i would be just a bunch of logic, like not null and not longer then, not containing invalid stuff etc. If it needs data from a location then just give that data as parameter so it could be a static validator that is something you probably can test without the need of mocks. So write tests to actually test something and not to hit a line of code just for the metrics

This will be tricky since the interceptor is declared once per assembly. Means the interception logic has to be shared amongst all the unit tests in the same project.

Thank you for explaining this new feature, but IMHO "old-school" mocking is less confusing.

Type classes are the replacement for interfaces, not interceptors.

yep, maybe if we do not need virtual extends or contract management, interceptor maybe useful for similar cases such as testing. Otherwise, even mappers kill readability, interceptor will have a nuke effect.

It's a bit of an assumption that interfaces are used to support mocking in the first place. Personally, I find that the third most important reason. The more important ones are: 1) enforcing loose coupling, 2) allowing multiple implementations, which has come in handy a lot of times. For example we have a multi-tenant system where each tenant gets their own database and some tenants are on old versions of the database. By exposing repositories as an interface, we can easily support multiple implementations corresponding to the tentant's database version.

This is so wrong i don't even know where to start. Why is the static class in the main project and not the test project? Do I need to build my code differently to run tests? What if I want to return something more interesting than `null` or `true`? Do I need to hardcode the same object in two places (test code and the interceptor generator)? What if different tests need different values from the mocked classes (e.g. to test how the MovieService reacts to a validation error)? Just use interfaces. They're simple, obvious, and your IDE can auto-generate one.

I'm not thrilled about Interceptors for test mocking purposes. It feels like too clunky of a system, at least until some serious work is put into doing a code-generating mock framework to create them. BUT then I have to ask what the benefit would be to using interceptors over existing proxy mechanisms? Or even Fody-style code weaving? It's hard for me to see how Interceptors either enable functionality we don't already have OR make improvements over existing functionality (like perf improvements, etc).

I don't know that it's right to say "interfaces are _abused,"_ though they may certainly be _overused._ Not everything _needs_ to be an interface, but I don't know of anything that's _harmed_ be being one.

The keyword here is “might”. It’s amazing but a no for me. Easily breaks when a new line of code is added but should be usable in certain scenarios.

Just give us more evolved constraints, such as the C++ 'Concepts', exposing possibilities by removing possibilities, being able to funnel down into functionalities that become inferable by the compiler.

Why would you use an interceptor for testing when an interface with mocking already solves the problem with a well-recognised pattern? Individual tests can set up the calls/results without needing multiple interceptors defined for the same calls. This appears to be a solution trying to solve the wrong problem.

This is very similar to how mocking functions works in python - and is really hard to maintain or understand the test. This normally shows a problem with the design more than an issue with the testing framework from my experience.

I'm not sure how I feel about this to be honest. But isn't that always the case when a new way of doing something comes out 😅. It feel wrong that the mocked file (source generated file) needs to be in the main project, when it's seems to only be used by the test project. Also, one reason to mock out a dependency, is that you then don't end up having to create multipe versions of a class for different scenarios. This feels like it could become that, if you have tests that check for different scenarios. In the video you just editted the MockGetSlugAsync method. But that would break your other test. On the plus side, having worked with bigs projects that have legacy code, that has then had to be re-written/re-architectured, this would save a lot of time and allow us to get tests in quicker. Maybe after they're in, then you could move to interfaces and mocking out. I'll have to watch your other video on interceptors and look into this more. Watch this comment become severely dated in a few months/years 🤪

I can see the value of new interception-based frameworks to help test code that wasn't written to be testable. That being said, I wouldn't use such a tool to inform my future designs as this is not a feature that replicates well across other OO languages. Sure, DI introduces a lot of abstractions, but the same design can be consistently replicated in different languages to achieve the same end result. Furthermore, it allows code to express itself as having no stakes in a particular implementation of a dependency, which is something you might miss out on if you decide to leverage interception just to avoid creating abstractions. Is this code actually tailored for a specific DBMS or do we not care? The abstraction tends to make that question clear. Abstractions also reduce the scope of the refactoring effort when changes need to be applied and isolates the associated risks. I don't feel like providing less abstractions provides such a significant benefit to warrant going with interceptions as the default. That being said, I think that interception-based testing will be an interesting option in at least two cases that I can envision: 1) Intercepting calls to static methods or other non-mockable constructs provided by a framework. This is fairly straightforward: we use a framework to avoid reinventing the wheel, so why should testing code that leverages a framework also have to test the wheel? Shouldn't this be the handled by framework developers? 2) When performance is critical and the overhead of adding and managing abstractions incurs a cost that needs to be avoided. Sometimes, you might need for code to be as fast as possible. And this means reducing the number of virtual calls and reducing the number of collaborators. This often makes code less testable without a setup that correctly replicates production-level conditions. With interceptors, you can verify the interactions that your code introduces in such contexts.

I would be happe to have this feature. It's hard to count how many things I've had to fix internally using Xamarin.Forms. So, instead of having the patched XF nuget package everything I need is to fix the wrong method. It would be nice to have access to private/protected/internal things too. It would be extreme cool to be able to combine this feature with the Source Link too. Just imagine you have some exception in the third-party library, you debug it using source link, then patch the method in 1-2-3 clicks!

This all reminds me so much of Harmony patching. It doesn't need to be in the main assembly, it doesn't require any changes to main assembly code; no attributes, partial classes, or any kind of markup at all. It can even help to "mock" (patch/substitute) internal, and private scope classes, and class members, without any "InternalsVisibleTo" additions. You can also cherry-pick implementations, by transpiling them, to substitute/mock block scope variables. Harmony has been used in the world of .NET game development for years, and has a huge audience. It's nice to see a form of monkey patching being implemented into the framework, but much like Newtonsoft, someone beat them to the punch a loooooong time ago. With any luck, Andreas Padeike might end up going the same way as JamesNK, and being offered a job at MS, to bring Harmony into the fold. harmony.pardeike.net/ Harmony is an incredible tool to work with. It's AccessTools, for working with Reflection are exemplary, and very highly optimised. I've made a NuGet package that harnesses the power of Harmony to make is very easy to work with reflection: www.nuget.org/packages/ApacheTech.Common.Extensions.Harmony github.com/ApacheTech-Nuget-Packages/ApacheTech.Common.Extensions.Harmony

Around the 7 mark I had a brief Fight Club flashback

that DeMuro cameo made me laugh tho

The fact that you need the interceptors in the source project is a deal breaker for testing purposes (even if it is source generated). This pollutes the shipping library with test artifacts, which is worse than the original problem you were trying to fix. If this generated interceptor code could live in another assembly that was just used for testing and not shipped, then maybe. (or generated into the test project itself.)

Unexpected Doug :)

So do we need a Carrier then?

In general the idea is very cool, but I suppose it will not be implemented at the nearest future as we'll need to sacrifice the "on-the-fly re-compilation" feature during tests debugging

This does only work for only one usecase. Seems also weird to debug or follow it since its jumping around.

Something that would actually help reduce interfaces would be discriminated unions if they ever get around to implementing them

What kind of Result class do you use?

Don't you think absolute paths in code are ok? After all, as if we were working together and this code I do not have the same path to the file as you.

i think it will make chaos in you legacy code base cause it suppose unit tests in another namespace and will affect i guess

cant you mock concrete classes using moq (or other mocking libraries) already?

Personally I struggle to see how maintainable code will be that uses this feature. Surely if you add in a new line or change the length of a variable or function name you’ll have to work everything out all over again?

Am I right in thinking that the test will fail when someone visit the class and decide to add a comment line as the interceptor won't be executed properly ?

Wow, that is really great feature for testing! But I want to ask you to use relative paths instead of absolute paths in your videos. It may confusing someone, especially newcomers, who are learning C# And they may wrongly thinking that it is ok to have absolute paths in code, which is obviously not ok.

no Nick, this is not a viable thing - any file change require changing location. Even if they introduce attribute like [InterceptorMark("blaBlaBla")] - i don't know what is worse

I've always disliked interfaces used just to support unit testing and DI. It's not what where their value is, and is only used there as a crutch for lack of a better mechanism. If your interfaces always have exactly one runtime implementation, then you're not really using them where they are beneficial. This makes it really hard to recognize when an architecture is using an interface for more than just to support DI, and it becomes obtrusive to decompose types into proper interfaces. Juval Lowy has some old talks on decomposing interfaces that I suggest everyone watch.

Is this logic need make interceptors inside one project or can be just injected from above? I mean does this allow hack usual calls between 2 different dll's calls?