SQL Server tries to use all available memory. SQL Server allocates memory during its activity. And, it only releases it when Windows asks for it.
This is normal behavior. SQL Server caches data into memory to reduce access to disk. Remember, SQL Server caches data pages, not query results.
You can limit the amount of memory available by setting the option “Maximum Server Memory”. By default, it is a ridiculous huge number: 2,147,483,647 MB.
SQL Server eating my RAM
This is specially true, if you’re running SQL Server on your development machine.
For your Production instances, check BornSQL’s Max Server Memory Matrix to set the right amount of RAM your SQL Server needs.
Voilà! This is a true story of how SQL Server was eating my memory. We needed some limits to keep things running smoothly on my laptop.
These days, I needed to update some unit tests. I found two types of issues with them. Please, continue to read. Maybe, you’re a victim of those issues, too. Let’s learn how to write good unit tests.
To write good unit tests, avoid complex setup scenarios and hidden test values. Often tests are bloated with unneeded or complex code in the Arrange part and full of magic or hidden test values. Unit tests should be even more readable than production code.
The tests I had to update
The tests I needed to update were for an ASP.NET Core API controller, AccountController. This controller created, updated, and suspended user accounts. Also, it sent a welcome email to new users.
These tests checked a configuration object for the sender, reply-to, and contact-us email addresses. The welcome email contained those three emails. If the configuration files miss one of the email addresses, the controller throws an exception from its constructor.
Let’s see one of the tests. This test checks for the sender’s email.
Our sample test only cares about one object: IOptions<EmailConfiguration>. All other objects are noise for our test. They don’t have anything to do with the scenario under test. We have to use them to make our test compile.
Use builder methods to reduce complex setup scenarios.
Let’s reduce the noise from our test with a MakeAccountController() method. It will receive the only parameter the test needs.
After this change, our test looked like this:
[TestMethod]publicvoidAccountController_SenderEmailIsNull_ThrowsException()// ^^^^// We can make this test a void method{varemailConfig=newMock<IOptions<EmailConfiguration>>();emailConfig.SetupGet(options=>options.Value).Returns(newEmailConfiguration{ReplyToEmail="email@email.com",SupportEmail="email@email.com"});// Notice how we reduced the noise with a builderAssert.ThrowsException<ArgumentNullException>(()=>MakeAccountController(emailConfig.Object));// ^^^^^// We don't need a return statement here anymore}privateAccountControllerMakeAccountController(IOptions<EmailConfiguration>emailConfiguration){varmapper=newMock<IMapper>();varlogger=newMock<ILogger<AccountController>>();varaccountService=newMock<IAccountService>();varaccountPersonService=newMock<IAccountPersonService>();varemailService=newMock<IEmailService>();// We don't need Mock<IOptions<EmailConfiguration>> herevarhttpContextAccessor=newMock<IHttpContextAccessor>();returnnewAccountController(mapper.Object,logger.Object,accountService.Object,accountPersonService.Object,emailService.Object,emailConfiguration,// ^^^^^httpContextAccessor.Object);}
Also, since our test doesn’t have any asynchronous code, we could declare our test as a void method and remove the return statement. That looked weird in a unit test, in the first place.
With this refactor, our test started to look simpler and easier to read. Now, it’s clear this test only cares about the EmailConfiguration class.
2. Make your test values obvious
Our test states in its name that the sender’s email is null. Anyone reading this test would expect to see a variable set to null and passed around. But, that’s not the case.
Make scenarios under test and test values extremely obvious.
Please, don’t make developers decode your tests.
To make the test scenario obvious in our example, let’s add SenderEmail = null to the initialization of the EmailConfiguration object.
[TestMethod]publicvoidAccountController_SenderEmailIsNull_ThrowsException(){varemailConfig=newMock<IOptions<EmailConfiguration>>();emailConfig.SetupGet(options=>options.Value).Returns(newEmailConfiguration{// The test value is obvious nowSenderEmail=null,// ^^^^^ReplyToEmail="email@email.com",SupportEmail="email@email.com"});Assert.ThrowsException<ArgumentNullException>(()=>MakeAccountController(emailConfig.Object));}
Finally, as an aside, we don’t need a mock on IOptions<EmailConfiguration>.
Don’t use a mock or a stub with the IOptions interface. That would introduce extra complexity. Use Options.Create() with the value to configure instead.
Voilà! That’s way easier to read. Do you have noise and hidden test values in your tests? Remember, readability is one of the pillars of unit testing. Don’t make developers decode your tests.
Do you want to learn React and you don’t where to start? Don’t look for any other curated list of resources. Let’s learn React in 30 days!
React is a JavaScript library to build user interfaces. It doesn’t do a lot of things. It renders elements on the screen. Period! React isn’t a Swiss-army knife framework full of functionalities.
To learn React in 30 days, start learning to create components and understand the difference between props and state. Next, learn about hooks and how to style components. After that, learn about managing state with hooks. But don’t rush to use Redux from the beginning.
Instead of reading books from cover to cover or passively watching YouTube videos, let’s learn React by doing, by getting our hands dirty. Let’s recreate examples, build mini-projects, and stop copy-pasting. If you’re instered in learning strategies, check my takeaways from the Ultralearning book.
These are some resources to learn React, its prerequisites, and related subjects.
1. Prerequisites
Before starting to work with React, make sure to know about flexbox in CSS and ES6 JavaScript features.
Redux could be the most challenging subject. You have to learn new concepts like: store, actions, reducers, thunks, sagas, dispatching.
Before getting into Redux, start by learning how to use useState hook, then useReducer, then useContext, and last Redux. It feels more natural this way.
Make sure to understand what to put into a Redux store and where you should make your API calls. Be aware you might not need Redux at all.
React Redux Tutorial for Beginners This is a complete Redux tutorial. It covers almost everything you need to know, from creating an store to testing your reducers.
Voilà! Those are the resources and project ideas to learn React in 30 days. Start small creating components and understanding the difference between props and states. You can find my own 30-day journey following the resources from this post in my GitHub LetsReact repository.
This post is about one of my hobbies: learning new languages. But not programming languages. Foreign languages.
I want to share three lessons I learned while traveling to France to practice my French-speaking skills. Each lesson is behind a funny story that happened on my first visit to France.
Don’t Fall into the temptation of speaking English. Keep speaking in your target language when locals talk to you in English. Don’t think they’re rude or you aren’t “worthy” of their language. They want to practice too. Ask politely to continue speaking in your target language. Or pretend you don’t speak English.
Learn vocabulary to suit your needs. If you’re traveling for work, vacations, or cultural exchange, you will need vocabulary for totally different situations. I learned this lesson while waiting at the security at an airport. Can you imagine what happened?
Mistakes are progress. Embrace it when locals correct your language skills. Don’t feel discouraged when locals correct your mistakes. Imagine you got a free language lesson. Probably you won’t make that mistake again.
How does the LIKE operator handle NULL values of a column? Let’s see what SQL Server does when using LIKE with a nullable column.
When using the LIKE operator on a nullable column, SQL Server doesn’t include in the results rows with NULL values in that column. The same is true, when using NOT LIKE in a WHERE clause.
Let’s see an example. Let’s create a Client table with an ID, name and middleName. Only two of the four sample clients have a middlename.
