[Event] SOLID with C#

Another event is coming. This time I will be talking about SOLID principles with C#.

I will be covering each one of them while we write a functional project using C# as language base.

If you want to join me, here is the registration link: https://mug-it.org.ar/event.aspx?event=521

A not so funny joke – Bad requirements

These days an image that is meant to by funny about our profession has been shared around different social networks.

This joke shows something that is expected from testers: Having a feature, try to think beyond the obvious behaviour and always look for ways to push the limit of what was implemented.

This makes perfect sense because developers tends to focus on the problem resolution but, due different constraints (Time, technology or knowledge) there are many cases that escapes to theirs intellect.

Although, this image pictures a different reality that is quite usual to find on projects: Inaccurate requirement descriptions.

If you use Scrum, you can call it “user stories“, if you use another, more traditional, model you could call them “use cases“. Anyhow, the problem of that picture is not the tester finding what could looks like the edge cases. The problem with the picture is what the tester is describing (And testing) are requirements that were never asked or were never shown to the developer.

This, let call it, anti management pattern happens so frequently that is accepted and added into the development process by all the stakeholder. From developers to mangers, even customers. All of them have naturalized this problem.

One of the most common reasons behind this behaviour is justified with fancy words such as: we are agile; the customer is not paying for this time; we can put this under the carpet (Or, technical debt if you don’t like to feel old)

In the other hand we must consider one of the golden rules of any developer: Do not code what is not need it.

This means that you should stop coding in the precise moment in which you, as a developer, start feeling that little voice in your head that says: C’mon, add that feature just in case…

So, again, what the developer did is almost perfect (It could have another type of bugs). Which is far from perfection. Far from be even an approximation of correctness if the requirements are discovered during the testing face. And there is a way to spot the problem, the way to know if we are suffering this anti management pattern: Count how many user stories are bouncing from developers to testers, and viceversa, that, for each bounce, the requirements gain in written lines.

Summarizing the idea behind this post I would say that picture IS a funny joke, but only if we forget those common problems that mine our projects: Poor requirement descriptions on the sake of feeling more agile; coded features making round trips from developers to testers and back, just because no one took the time of be sure that the requirement were correctly written down.

Mock objects for unit testing with Lua

From the last post, I have explained the first basic steps to start unit testing Lua code. Clearly, those tests were very basics and, usually, will not represent the most common case scenarios of real, production level, code.

In any development (Unless that we decided to use a different coding paradigm) having objects that encapsulate functionality is the common pattern.

Those objects will contains functionality in form of functions, methods and other structures. It will handles data, expect data and produce data. And, of course, we need to test these interactions and results.

Testing injecting dependencies

We will start with something simple: Functions that depends on objects.

This is clearly a very common scenario. You have a function that requires the services of an object. At some point we will test the object but, to keep it simple, we need to test the function that consumes the services of this object and produce a particular result.

function IsUserMinor()
    local age = IdentityService:GetUserAge()
    return age <= 18

In Lua we can have global and local variables. The previous example could look odd if you come from pure OOP languages. It is clear this function is coupled but, and here is where the Lua magic enters in play, that IdentityService object could be, in fact, anything. For sure we could have passed this as a parameter but, again, due the nature of Lua, this function is grabbing the object from the context, which can be anything (Saying that, I will bring a better version in following posts).

So, we have this function in one single file. The function checks if the user is a minor or not and returns a boolean. Very simple but: how is it this running? You may ask (I hope so).


local isMinor = IsUserMinor()

if isMinor then
    print('User is minor')
    print('User is not minor')

As can be seen in this file. It is this file the one that creates the context. Putting together the file with our function, the file with the Identity Service object and some small code. Considering this is possible to do, we just need to replicate these conditions in our tests.

Creating a mock object

A mock object is a representation of the object that we want to substitute but with custom functionality that we can control. The original object, IdentityService, could be trying to connect to a data base or a directory system requiring more services and configurations that we do not want to orchestrate for a test, and in particular, for unit testing our function. Just think on all the possible prerequisites, including a testing server with fake data only to avoid touch real data. Also, real data can be modified by external agents which will cause our tests to fail: We need to have control over our tests.

mockObject = { }
mockObject.__index = mockObject

function mockObject:new()
    local obj = { }
    setmetatable(obj, mockObject)
    obj.attributes = { }
    return obj

function mockObject:GetAttribute(name)
    return self.attributes[name]

function mockObject:SetAttribute(name, value)
    self.attributes[name] = value

In Lua, this can be consider a standard object in which we have added two properties: GetAttribute and SetAttribute. We will use these properties to allow the test the creation of properties and values that could be required by the different scenarios.

Injecting the mock and testing

As I said at the beginning. We need to replicate a similar execution environment allowing us to use the mock instead of the real object.

local luaUnit = require('../unittest/luaunit')

function mockObject:GetUserAge()
    return self.attributes['age']

IdentityService = mockObject:new()

Because we can add functions into our objects. Adding the GetUserAge function is need it. This function will retrieve a particular attribute “age” which will be injected during the test preparation phase.

function DoTest(age, expected)
    IdentityService:SetAttribute('age', age)
    local result = IsUserMinor()
    luaUnit.assertEquals(result, expected)

As in the previous post, the DoTest function acts as a helper and encapsulates the code to be reusable. In it, the expected age is set before calling the function that is being tested. Remember, the object IdentityService is global and was previously declared in this execution context. This will ensure that IsUserMinor function is still able to find this object and use it.

Finally, we need to declare our test.

DoTest(10, true)

It is important to clarify this approach is not totally correct. As I mentioned some lines above, the function itself is coupled and more work can be done but, from testing perspective, the injection of the object is still pretty good.

First steps testing Lua code

Lua might be one of those languages which few have heard about it. Usually there are no job offers from companies looking for Lua developers as for C#, Java or any new fashion JavaScript framework.

But, there are a reality and is that Lua is there, behind many big systems, videogame engines and servers.

It is quite common to use Lua for add functionality to these systems. Perhaps one of the most known systems that uses Lua is Roblox. That videogame application that gather thousand of players and, in which, you can create your own 3D games and make some money on the process. But, as I said, as with Roblox, there are many other places in which Lua is required and having some knowledge around this language could be something to consider for any developer toolbox.

So, I will assume that you already have some basic knowledge of Lua, but if you don’t, no worries, I will use very simple example which any developer could understand. And, of course, the important part here is testing over Lua as a language.

Creating code to test

Clearly, something that we need is some functional code to test. For the sake of this post (Keep it simple) we will write a couple of basic functions:

function sum(a, b)
    return a + b

function substract(a, b)
    return a - b

Now we have some code and the question that requires an answer is: How we test this?

The testing framework

It is clear that for unit test any piece of code you don’t need a framework. A framework could give you some benefits but not having one is not a blocker. You can still test without a testing framework. In any case, we will use one 🙂

We will use Lua Unit, which has a wide set of functions to help us during the testing process. So, lets create another file in which we will write our unit tests.

--import Lua Unit
local luaUnit = require('./luaunit')

--import math functions file

Lua Unit can be fully downloaded in one single file and included into our testing file using require command. In the same way, we can import the functions to test from the file in which we wrote them.

Unit testing our code

Having imported the files and the framework, the next step will be to write the testing code. One good practice for unit testing, as in any other language, is to encapsulate any data initialization and repeated code in such way that we can reuse it, helping the functional test to focus on that action: testing.

function DoTest(valA, valB, expected)
    local result = sum(valA, valB)
    luaUnit.assertEquals(result, expected)

In the previous code, the function DoTest parameterize the test process allowing any other test to consume its services and act in consequence.

function When_Sum10and10_Expect_20()
    DoTest(10, 10, 20)

The testing function follows one of the many naming conventions (Which can be changed at will) and encapsulate what need to be tested. Depending of how we are use to do testing, we could expect to have the assert call inside of the test and not in the helper function.

Finally, we need to perform a call to this function and execute the test.


If all goes good and the tests pass, Lua Unit will do its work and no messages will be shown. In the other hand, we can let Lua Unit to show more detailed information about the execution adding the following at the end of our script.

os.exit( luaUnit.LuaUnit.run() )

But even without the previous line we will be getting error messages if any unit test fails, having an instant feedback of our code.

Reading and writing data into a BBC Micro:bit without a single line of code

BBC Micro:bit

The BBC Micro:bit is a microcontroller board that, as far as I know, was built it thinking on young people for help them to learn coding.

If you are not aware (Like me) this board will pass you away easily thinking that is limited and is only for basic stuff.

The reality is the absolute opposite: This board has so many sensors, leds, buttons and pins to use that, having the same set on an Arduino will require a full box of parts.

Of course, I am not saying this is BETTER. Just saying this is really GOOD!

Anyway, marketing aside, I have had this sitting on my desk for almost a year without even trying to understand its power. Last night suddenly something happened: I look at it, it look at me and challenged me: I challenge you to write and read data from me without writing a single line of code! – It said… ejem! Sorry… I too earlier and I have not had my coffee yet.

Nevertheless, something close to that happened. I started wondering how we could send and receive data from/to the board without using the traditional processes: Coding something in C. Reading the serial output with Python. Etc.

Well, clearly we will need to use a communication channel and the serial port is, perhaps, the simpler. In the other hand, remember, “no coding” is the premise. So, what do we have in the operating system that could help us? We will discuss this later, but first, the board.

I lied a little bit: We do need some code! But, not in the traditional way. For the micro:bit we can use blocks to create a basic sketch that opens the serial for us.

Because this is intended for young people, using this building blocks makes the code creation super easy. And the most important: trivial.

With the previous code then, we are setting the serial ready, expecting data from the serial port and using the front led matrix to write the incoming message and writing into the serial the values from the internal board compass with a refresh rate of 500ms.

So, how we read and write data? We need to know which port the board is using. For this we could go to our devices and search there OR, type some command lines. Clearly, we will type command lines.

Opening a command console and typing MODE will list the connections

On the previous image we can see the device is connected to the COM4. One thing that we need to notice are the properties. Depending how much control do we have over the code deployed into the board, we could decide the bauds speed and other properties. By default 9600 bauds will not work or, at least, the data transferred will be “broken” (Let use this name). We will need to set the this property to 115200 bauds.

Using mode COM4 baud=115200 parity=n data=8 we set the expected configurations for this board

Now we have all set and ready to write something into the board. Another command will help us on this.


echo” is used to print into the console if we used without any other property. On the console, the arrow head (>) means direction. For this case, echo will print the text INTO something. That something is the COM4. Technically we could print to any other connection such as printer or a file.

Now we wrote into the board. How we read from it? Easy!

type COM4

There are a couple of ways to read from the port, the easiest is using type command. This will open a connection with the board over the designated port and listen anything that is sent by the board.

So, I have not completely lied :). Without writing a line of code and only using what the OS provides we were able to read and write from a board like this one.

NetCore Conf

The NetCore Conference has passed. And 29 sessions with more that 5000 viewers are the final results. Not bad at all!

My lecture was streamed a couple of hours ago and, because this is Internet, will be on YouTube if you missed it or if you want to see it again.

As I mentioned in a previous post, I was about to talk about performance on .Net Core with C# but in particular, showing two examples of how performance is affected when, for the first scenario, the overuse of some libraries (On special cases) could cause more harm than benefits. And for the second one, how our coding style could affect the performance forcing the compiler to add more unnecessary instructions to the IL code.

In any case, if you want to take a look to the lecture: