While my experience is mostly C++, I assume these mocking libraries are similar in allowing you to create a class that can report it’s own usage, and allow for arbitrary returns values and side effects, which is incredibly useful, especially in conjunction with dependency injection.
What patch lets you do is directly overwrite the functionality of private member functions on the fly, which if Java/JavaScript can do I’d love to know, I thought this was a uniquely Pythonic magic.
Oh I’m fully aware that python lets you cheat dependency injection with patch, its one of the many things python teaches developers to do wrong, which leads them to be unable to use any other language.
Exactly, have fun trying to get test coverage without dependency injection
I’m a software engineer and I’ll discuss it with you, rather than just down voting and walking away.
Your use case for AI allows it to excel. Writing self contained scripts and small pieces of functionality for automation is a great use case for AI, but it isn’t what software engineers do. There is a saying that you won’t have a design problem in a code base under 10,000 lines, then all you have is design problems, and this is what AI is bad at. It can’t maintain or update or extend much larger code bases, and it can’t interpret user vagueries into concrete requirements and features.
For me it is useful for prototyping, and for boilerplate code where I know exactly what I want but its faster to prompt it than to type it all out. I wouldn’t use it for anything critical without carefully reviewing every line it generates, which would take longer than just writing the damn code.
I also have a big problem with the reliance a lot of people are building on AI. Remember how every other service you’ve used goes through ‘enshitification’? This will happen to AI. Once they need to be profitable and the shareholders need to get paid, the features will get worse and the prices will go up, and you will have to pay those prices if you can’t work without it. Just something to bear in mind.
Use it if it’s useful. Don’t become reliant on it. You seem interested in coding, why not try coding something simple yourself? Try looking up the documention to see if you can use your wet brain first, and only go to the AI after. You might find you actually enjoy it, or solve problems faster because you remember how you solved them before.
For playing with, rather than ‘serious’ projects
Did the generated code get merged? I’d be curious to see the PRs
Source: vibes
Sorry random internet person let me forward your opinion to my old Computer Science professor and have them update it.
AI as a field goes back to the 50s, long before any concept of machine learning, or what ‘intelligence’ was possible for a computer to achieve.
AI in the computation sense can refer to any system that appears intelligent. This includes simple logic. It seems to be you that is confusing AI with Machine Learning.
I feel like there are two concepts be at confused here. ‘Mocking’ is just replacing an actual implementation with one that reports its usage, so calls or lack thereof can be asserted to occur, and tests can fail if that condition is not met. They usually allow setting side effects and return values on a per call basis also, to inject different behaviours for covering different code paths easily.
The question is then how do I get a class like DatabaseWrapper to call into an underlying mockDB instead of the normal realDB? The answer, in static languages is dependency injection: the db object must be constructed externally to the wrapper, and passed in in such a way that any object with the same interface is acceptable.
This allows the tests to pass in a mock with the same interface, and have the class being tested accept it. The class will then run as usual when its methods are called, but we can make assertions about how it uses its dependency. In some languages, such as python (and it seems JavaScript as well) this can be bypassed by monkey-patching the private member dynamically after the object has been constructed to be the mock instead of the real.
Personally, I don’t think this leads to good design. Dependency injection also allows for a nice port and adapter pattern, were in the future we might replace our SQL database with a MongoDB one, and we have to rip up the application, instead of just implementing a new db class that meets the interface, and injecting that into the wrapper instead.