With C++ I like unit test functions or classes to be friends of the classes they test. That way I am not limited to the public interface. I need less mocking or boilerplate to test all methods. At the same time separating public and private methods.
With Vala is made most methods public to be able to test them. This exposes too much of the class interface.
Is there a way to make unit tests (classes or functions) friends like in C++?
I asked in this Vala chat(you can try it). The short answer seems to be no. There is a dead framework for testing ValaDate.
Related
I am new to .net core and I am trying to port some old .dot net code.
Up to now I was using lots of static helper classes. One example is a class called 'ImageUtilities' that offered static methods like 'ResizeImage(..' or 'ResizeAndSavePNG(..' and so on. Or an other class is 'DateUtilities' with methods like 'GetCalendarWeek(..' or 'GetDaysBetween(..' This are just some examples, could be any static class.
Wher ever I needed one of those methods, i just called them. With .net core I could still do this but I would like to improve my code and try to follow best practice guidelines. This is why I changed this to use Dependency Injection.
Now in my startup class I have lots of code like this..
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton<IImageProcessor, ImageSharpProcessor>();
services.AddSingleton<...
services.AddSingleton<...
services.AddSingleton<...
}
ImageShorpProcessor is a class that represents my 'old' class 'ImageUtilities' of the old .net net code. If a class now needs to call some of those methods I pass that class ImageSharpProcessor with Dependency injection in the constructor. This works very good and I hope this is the way to do it.
But in my application the ImageSharpProcessor class is rarely ever used as an example. And this is where my concerns start. 99% of the users of the website do not use the pages where this class is used in the code. The same applies to a lot of other helper methods which used to be static classes but now are methods that are used with Dependency Injection.
Question:
Is this the proper way to use such util classes, that used to be static classes now with Dependency injection although they are rarely ever used in a website? Does the instantiation of all those classes like services.AddSingleton<... slow down the startup process of the Website? Or are they instantiatiated only at the point where they are used for the first time?
I hope you unterstand my concerns. Hopefully someone can give me some advise on that topic. It would be appreciated! Sorry for my english, best regards!
Does the instantiation of all those classes like services.AddSingleton<... slow down the startup process of the Website?
NO.
Registering them with the DI container does not affect performance, provided that they are simply registered and not initialized before adding them to the container.
Or are they instantiated only at the point where they are used for the first time?
Those singletons will only be initialized when or if the page/class that needs them are initialize
The fact that they are not used frequently is of no consequence. The fact that they are used at all in the system for it to perform its function is the reason why tried and practiced design principles should be applied.
My question is about using final keyword im Swift code. I know that final helps compiler to compile code faster because of dynamic dispatch. So, if I definitely know that I will not inherit some of my classes, should I make all of them final?
There was this protective approach taught by the iOS Stanford course.
The approach was, define all your APIs private. It increases encapsulation. Later if you needed to give away something then remove the privacy.
Because it's bad to do it the other way around ie design something public and then later change it to private.
Similarly here, I think making a class final and then later deciding it shouldn't be final is better than making a class non-final, allowing multiple classes to subclass it and then later attempt to revert it back to final because of some design decisions.
You are fine to do so if you are 110% you won't attempt to subclass any of your 'final' classes, as your project won't compile if you do so.
The article below has some great information and should help you decide.
http://blog.human-friendly.com/the-importance-of-being-final
If your app or a framework uses a protocols over inheritance then you can define your class types as finals.
If you prefer to use an inheritance over protocols and your app or framework is tested with a Unit Tests then don't define your class types as finals when they are used for a dependency objects because they will not be able to be mocked.
I have an F# library with lots of non-public stuff I want to test. Currently all code that is not part of the assembly's public API are marked internal (specifically, it's placed in modules that are marked internal). I use the InternalsVisibleToAttribute to make this code visible to my test assembly. However, in order to get the test assembly to compile, all tests that use internal types in their signature (most of them, since I use FsCheck to auto-generate test inputs) must also be marked internal (this needs to be applied to each function, because internal modules won't be discovered by xunit). Additionally, any types used exclusively for FsCheck generation (e.g. type ValidCustomer = ValidCustomer of Customer where Customer is my internal domain type) also need to be marked internal, and FsCheck seems to get stuck when creating internal types, so the tests don't run.
Is there any way to test internal F# code (from a separate test assembly) without having to mark all tests whose signature depends on internal types as internal? Right now I'm simply leaning towards not making anything internal at all in the original code, but ideally there's a way to have my clean-API cake and eat it too.
I've found that the OO world will generally be very opposed to attempting to test anything internal/private directly.
In the functional world I've seen more of a tendency to just expose public functions not intended for public use so they can be tested. See this comment from Edward Kmett.
When I started writing Haskell I started rethinking the way I used to approach encapsulation and hiding.
...
In general I'm a big fan of exposing all of the salient details, constructors and all for my data types through some kind of .Internal module, even if I want encapsulation and safety in the rest of the API.
...
As a side-effect of that you can then use these newly exposed guts to do nice testing. =)
There's a lot more detail in the original comment, and there is a talk where he discusses this at length but I can't find it now.
You could also give the module a really ugly name like __INTERNAL__ to discourage its use.
I have a static library in objective-C that has 1 main class, which is the delegate to multiple classes and includes delegate methods to handle server calls and location updates. Since I'm developing a static library, only logic unit test is supported. I'm having a hard time coming up with test cases. I read articles on unit testing that suggests not to test private methods and constructors. I wrote basic tests like testing a async method that makes an api call and checking the delegate method's return value. What is a good starting point when creating logic unit tests for a static library?
Since I'm developing a static library, only logic unit test is supported.
Actually, you can create a little app to serve as the test host. Then you're not limited to logic tests — you can test anything you want. You can test every aspect of your class.
Heyho,
There´s a question in my mind for some time now, which hopefully can be cleared quickly by some of you:
I am a big fan of MVC, ASP.Net Mvc in my case.
What I have noticed is the hype about interfaces. Every video, tutorial and book seems to solve any kind of abstraction with interfaces. I have adapted these patterns, understood why and how and I am basically very happy with it.
But I just don´t get why interfaces are used everywhere. I´ve almost never seen some abstraction being done with abstract base classes, which I don´t understand. Maybe I miss something? I know that you can only inherit from one base class while multiple interfaces are possible. But interfaces do have disadvantages, especially when some changes need to be done, which breaks your implementations.
In my projects so far, I only used to pick interfaces for completely different classes.
For example, the whole repository pattern could be done with an abstract base class, still providing testability and exchangeability, or did I miss something?
Please point me to the part where my brain laggs :)
Interfaces are used in tutorials, blogs and elsewhere because those authors are particularly influenced by a group of methodology called "design for testability".
Primarily, design for testability school of thoughts used interface every way because they want to be able to mock any component under tests. If you use concrete class, then a lot of mocking tools can't mock those class, and hence will make it difficult to test your code.
A Story
I once attended a Java user group
meeting where James Gosling (Java's
inventor) was the featured speaker.
During the memorable Q&A session,
someone asked him: "If you could do
Java over again, what would you
change?" "I'd leave out classes," he
replied. After the laughter died down,
he explained that the real problem
wasn't classes per se, but rather
implementation inheritance (the
extends relationship). Interface
inheritance (the implements
relationship) is preferable. You
should avoid implementation
inheritance whenever possible.
While using only or mostly Interfaces does have code reuse problems(as well as eliminating nice base classes), It makes it a lot easier to do Multiple Inheritance like things. As well as having widely different implementations that will work and where you don't have to worry about the base class changing or even what it does(you do have to implement the whole thing though so its a trade off).
P.S. I think the new Go language is based on interfaces rather then inheritance(looks sort of interesting).
If the language doesn't support multiple inheritance or mix-ins abstract base classes are limited in scope compared to interfaces. E.g. in .NET if you must inherit from some other type such as MarshalByRef, you can't use an abstract base class to implement a pattern. Interfaces do not impose this restriction.
Besides the fact you mentioned that you can inherit from a single base class only (which is pretty inconvenient if you want to use an existing class that already inherits from some class with the new framework base class), you also avoid the fragile base class problem if you use interfaces instead.
Coding against interfaces makes your design more flexible and extensible. For instance, plugin frameworks and dependency injection. Without interfaces, the extensibility of it is pretty much limited.
Read about interfaces, abstract classes, breaking changes, and MVC here: http://ayende.com/Blog/archive/2008/02/21/Re-Versioning-Issues-With-Abstract-Base-Classes-and-Interfaces.aspx.
One solution that is presented there (or somewhere else on Ayende's blog) is: do use interface but also provide abstract classes. Those who case about breaking changes can base their implementations on abstract classes. Those who need power of interfaces are also satisfied. But do make sure your methods accept interfaces, not abstract classes, as input.