Casting to type variable – generic without Generics

Sometimes you cannot write simple generic code like Method(). When is that? Well – in unit tests for example. Imagine you have test that needs to run multiple times – each time for different type. Solution I’ve witnessed in production code is to write separate test for every type and copy-paste the code around. Terrible, terrible solution!

Another way could be to create separate tests, but extract common code to external method – now we can use generics – and just call that method. Much better, but still – having dozen methods just to call other one? There must be a better way!

And surely there is – data driven tests. [TestCase] in NUnit, [Theory] with for example [InlineData] in XUnit or even poor [DataSource] in MSTest. But it cannot pass generics, test method cannot be generic.

So I looked why exactly this test requires generic type. It all comes to this

try
{
    T result = (T)variable;
}
catch (Exception)
{
    Assert.Fail();
}

So just casting to see if object is of given type. I didn’t want to mess with test logic to much, just to reduce code quantity. So how do you write casting code without generics and knowing just the type (because we can of course get Type variable as parameter)? Simple as that:

object result = Convert.ChangeType(variable, type);

Is it perfect? Of course not – it returns object because it does not know the type it’s casting to. It might not be all that useful then. But in my case – it fits perfectly. Throws the same exceptions if casting is not possible, verifies if object can be assigned to variable of given type as the old code did. And now I can just have one test method with dozen test cases in it!

Advertisements

Don’t be afraid of changes

Early this year I changed companies and started working for a bank. They promised me working with highly specialized software, global standard in its category. And they promised me .Net platform. First they delivered, second they failed for more than 9 months now.

Now I do complain a lot. But at the same time I am afraid of acting on what I feel. So I tried explaining it to myself that this is just temporary, they will update their software, we will go forward. Now I finally see things as they are – change is no coming any time soon. And its my life and no one will take care of it better the myself.

I’ve raised my issue to people above me. And starting from next week I’ll be back at .Net project, WPF, WCF, tasks – you name it. It wasn’t hard. All it took was a bit of honesty about the situation and idea on where I would lie to be and everyone was happy to help.

Don’t sit quietly in uncomfortable situation, take care of your professional life and be honest about your work. The world is your oyster!

Documentation matters

Agile. Lean. Extreme Programming. Yadda yadda yadda. Over and over again. Day after day.

The thing is, business likes to think agile is whatever suits them at the moment. Be it changes in requirements every week, lack of proper testing or defined process of work. Or lack of documentation. Why would you need one? Code is self documenting. We have power point presentations. We have sharepoint!

But at one point you are going to work with one, huge environment. Different applications. Most of which you have never heard about. And someone reports a bug. Data in system Ypsilon is incorrect! Fix it ASAP!

I took my time trying to figure out what is this Ypsilon unicorn I’ve never seen before. No idea. Called few guys, got some answers but nothing that would put me any closer to fix. But I knew that Alpha system I was working with most of the time was producing csv file with data (yup, 21st century and we’re still sharing data using csv with bad formatting and FTP). But the code there wasn’t touched in 3 years. So how it suddenly broke when October started?

But everyone was convinced that Alpha system was broken. Fun part was when they were telling me what data was expected in file. “Column A needs to have 111!”. Next day: “Column A needs to have 543!”. Later: “Column A needs to be 111! Don’t change it!”. They didn’t know themselves.

Week passed when they were trying to figure out what’s wrong with data in the first place and what’s the real error they are experiencing. Today few guys finally sit down, looked at the data they are getting, looked at few systems and figured: it’s not Alpha’s fault! It’s Gamma that’s wrong! Yup, you got it. I barely knew Gamma system exists, even less what it does.

How could this time be saved? With documentation. First – global architecture of the system. What systems are working together. How they are sharing data. WHAT they are sharing. Second – documentation of interfaces. If system produces output that’s being consumed by other systems it needs to be documented well. We can’t leave it to code. Code changes. Not everyone has access to code of every system. This leads to other developers making assumptions based on names of columns (if those are named in the first place) which can be misleading. And those assumptions may be based on small subset of data and not right in long game.

Have we had documentation finding bug could take one day. Not seven. Or we could not have bug in first place.

Lack of documentation is not agile. It is just stupid.