So I have this fake object definition, that has a fake method in it :
// Note: This is a simplified version of my code.
// If it turns out that such issues could come from complex method prototypes,
// then I'll post the full setup.
IFooRepositoryClass fooRepo = A.Fake<IFooRepositoryClass>();
A.CallTo(() => fooRepo.FooFunctionAsync(A<Guid>.Ignored).ReturnsLazily(
(Guid fooId) => {
fooInternalObject.DoSomething(fooId);
}
);
As you can see, nothing out of the ordinary.
Later, in my XUnit tests, I call the fake function :
Guid testGuid = new Guid("aaaaaaaa-9a88-4746-914b-aaaaaaaaaaaa"); //I changed to "aaaaa" to make it easily recognizable
await fooRepo.FooFunctionAsync(testGuid).configureAwait(false);
I put a breakpoint on that instruction :
await fooRepo.FooFunctionAsync(testGuid).configureAwait(false);
...I see that testGuid is indeed aaaaaaaa-9a88-4746-914b-aaaaaaaaaaaa
But then I put a breakpoint inside, on this instruction :
fooInternalObject.DoSomething(fooId);
To my great surprise, fooId has a weird value with lots of zeros, different at each run!
f933b838-007b-0000-0000-000000000000
785bb288-001a-0000-0000-000000000000
4d4bb8d8-0012-0000-0000-000000000000
etc.
As you can see it's not Guid.Empty, just Guids that look suspiciously manufactured.
What the hell is going on? Can FakeItEasy do that to Guids?
Even weirder : I shared my branch to a colleague, and he checked it out. So he has the exact same code as me.
...But for him, fooId has the expected value, i.e. the value of testGuid! We peeked at each other's screen and every execution conditions seem identical. Only the Guid differs at the breakpoint : Expected value for him, bogus values for me. I cleaned the solution, rebuilt, even restarted VS. to no avail!
What the hell is going on? x2
I'm not expecting anyone to fix my unit tests, but maybe this is a well-known behaviour under certain conditions. Ever seen that? Especially those weird 000000 Guid values? Something has to differ between our setups, but I need a lead to know where to look.
Related
I have a test that compares the equality of two pointers to instances of a struct (MyStruct). The pointers are stored within other structs (container1 and container2). Here's how I check the equality:
require.Equal(*container1.MyStruct, *container2.MyStruct)
the Equals() method is from the Testify library: https://github.com/stretchr/testify/blob/master/require/require_forward.go#L128
This test passes when I run it on my Mac. However, when I push my changes to our build server (Linux), the test fails. The error message is the standard Error: Not equal... message, but when I diff the expected and actual shown in the output, they're exactly the same!
I thought maybe Go is somehow comparing the addresses of the pointers rather than the contents, but the comment on require.Equal makes this seem unlikely:
// Pointer variable equality is determined based on the equality of the referenced values (as opposed to the memory addresses)
Any idea what's going on here? Does Go behave differently on Mac vs Linux?
I'm not able to post specifics here as it's an issue I'm seeing in a codebase I touch at work.
The problem is that there's a bug in the output of the Equal function's "expected... actual..." printing logic for structs when the struct contains a Time object. Here's a snippet from the error output: (I've removed the irrelevant fields of the struct):
Error Trace: my_test.go:388
my_test.go:50
Error: Not equal:
expected: {
BuildStartDateUtc: 2020-08-17 22:43:05.330062876 +0000 UTC,
actual : {
BuildStartDateUtc: 2020-08-17 22:43:05.330062876 +0000 UTC,
}
Fields look the same. However, if I compare MyStruct.BuildStartDateUtc directly, I get this:
expected: &time.Time{wall:0x389ccfe6, ext:63733398658, loc:(*time.Location)(0x101d4e0)}
actual : &time.Time{wall:0x389ccfe6, ext:63733398658, loc:(*time.Location)(nil)}
The "loc" field is missing in the actual. This is what's causing the comparision to fail, but since "loc" evidently is not included in the output when we compare a struct that contains a Time, we get a very confusing "expected... actual..." output where the actual/expected look exactly equal when they're not.
When I syncronized the Location of the Times being compared the test passed.
Looks like it might be related to this Testify issue: https://github.com/stretchr/testify/issues/984
I would like to know if there is a message I can override in Pharo so that my custom classes display more descriptive information in the inspector/debuger much like simple variable types do, like Integers or Strings. For instance:
Instead of that, I would like it to show a more custom and informative description consisting of its internal variales so as to have a tighter/tidier view of the variables instead of having to click on it and open another chart (therefore losing sight of the information on the previous chart). I know you can increase the amount of charts shown below, but that is not the point of the question. I would like to achieve something like this:
I have browsed the pharo forums and found nothing, I have also tried overriding over 30 methods hoping that one of them changed the output. Only the class message seemed to change the output, but I could only return an instance of Metaclass and besides messing with this message would break a lot of stuff. Finally I tried to reverse engineer the debugger and then the inspector to see at which point is the table constructed and what values are used or which messages are sent to build said values, but it was just too much for me, the callstack kept growing and I couldn't even scratch the surface.
Luckily, doing this in any Smalltalk is very easy. Types inherited from Object are expected to answer to the message printString, and ultimately printOn: aStream. Those messages are expected to give a description of the object. So, you should just override printOn: in your class (printString uses printOn:) and all the browsers and inspectors will automatically use it. There other possibilities in Pharo, if you want to provide more complex information in different tabs, but I think printOn: will suffice for you.
An example would be:
MyPoint>>printOn: aStream
aStream nextPut: ${.
x printOn: aStream.
aStream nextPutAll: ', '
y printOn: aStream.
aStream nextPut: $}
In Smalltalk, every time you observe something you don't like or understand, you ask the question: Which message is doing this?
In your case, the question would be: Which message creates the string a MyPoint that I see everywhere?
Next, to answer your question you need to find a good place for inserting a halt and then debug from there until you find the culprit. To do this just find the simplest expression that would reproduce the issue and debug it. In your case the right-click command in the Playground will do. So,
Write and select (MyPoint on: 14 and: -5) halt in a Playground.
Right-click and issue the Print it command (I'm assuming you already checked that this command produces the string 'a MyPoint').
Debug
Go over the evaluation of #DoIt, which answers the result
Continue this way alternating between Into and Over to make sure you follow the result to where it's being taken
Eventually you will reach the implementation of Object >> #printString. Bingo!
Now you can open a System Browser and take a look at this method, study how it's been implemented in different classes, etc. Your investigation should show you that the most basic message for printing is #printOn:. You may also want to take a look at other implementors so to better understand what people usually do. (Bear in mind that writing good #printOn:s is a minimalist art)
Overriding printOn: will work for simple cases where you want to just change description.
Pharo allows a lot more than that!
Due the extensible (moldable) nature of our inspector, you do not need to override a method to get your own visualisation of the object.
For example, look this array visualisation:
This is obtained adding this method to Collection:
gtInspectorItemsIn: composite
<gtInspectorPresentationOrder: 0>
^ composite fastList
title: 'Items';
display: [ self asOrderedCollection ];
beMultiple;
format: [ :each | GTObjectPrinter asTruncatedTextFrom: each ];
send: [ :result |
result
ifNil: [ nil ]
ifNotNil: [ result size = 1
ifTrue: [ result anyOne ]
ifFalse: [ self species withAll: result ]
]
]
if you browse for senders of gtInspectorPresentationOrder: you will see there are already a lot of special visualisations in the image.
You can take those as an example on how to create your own, adapted exactly to what you need :)
I've been writing an app that involves using NSUserDefaults to store a few Int variables and it's been working fine. I thought I was finished and was doing some final testing and one of the first lines of code that I wrote, and that has been working consistently before, has failed me.
Apparently the green line error is supposed to occur if I try to unwrap an optional that has a value of nil, but this variable is still very much an optional
var savedTotalSeconds: Int? = userDefaults.objectForKey("totalSecondsKey") as Int?
Why would this possibly return an error? It was working fine before and I only changed things I thought were unrelated to it. In the app I have a button to remove this stored value via:
userDefaults.removeObjectForKey("totalSecondsKey")
What could possibly have gone wrong?
Try using 'as? Int' instead of 'as Int?'
The difference is that the first one tries, and might fail, at casting to Int. That failure will be captured in the optionality of the resulting variable.
The second one tries to coerce the object to 'Int?'.
I've hit a pretty major snag with the entities generated by spmetal / linq to sharepoint. I am hoping someone has dealt with this before.. or maybe I am missing something obvious.
Let's say we have a list with a number field. The field will be expected to hold reasonably precise values.. for example, 0.0000451. Once the value is in the list- SharePoint is fine with it. It displays in the list and display/edit views correctly.
Now if we generate entities based on this list with spmetal, we will get..
//...
private System.Nullable<double> _number;
//..
[Microsoft.SharePoint.Linq.ColumnAttribute(Name="Number", Storage="_number", Required=true, FieldType="Number")]
public System.Nullable<double> Number {
get {
return this._number;
}
set {
if ((value != this._number))
{
this.OnPropertyChanging("Number", this._number);
this._number= value;
this.OnPropertyChanged("Number");
}
}
}
//...
Since the type determined by spmetal is doublewe get notation when trying to retrieve it.. for example:
var number = (from x in myDc.MyList select x.Number).First();
number would actually result in a double of 4.51E-05, not 0.0000451.
I am assuming this can be fixed by using a decimal. If I change the types throughout the generated entities to System.Nullable<decimal> I get type conversion failures.
How should I fix this?
EDIT I think maybe it is better to ask "how should I deal with this"? for example, I can simply convert my double values to decimal later on down the line.. my linq query, for example. If I do that, the example case would return the expected result. That seems clunky, though, and I'd like to correct this at the source.
There are several cases like this where SPMetal will give you clunky code. You can, and sometimes have to, fix that. And I admit, it definitely feels better to do it at the source.
But there is a downside.
When your data model changes you will have to re-run SPMetal to incorporate your new entities. Any changes you made to the generated file will have to be carefully documented and re-done, or your code will be broken. Therefore, I would advise to leave the generated code alone if you can work with it.
If you can write a wrapper around the objects/methods it would of course be preferable to just converting the types at the end-point, but that's general good programming practice.
4.51E-05 actually equals 0.0000451 so there is nothing wrong with your code.
In other words 4.51E-05 means 4.51 times ten to the minus five power, or 0.0000451
So I'm doing some business logic and want to run some code that goes like
select id from blah where foo = 1234 for update nolock
This code throws a DataMapper::SQLError when the corresponding row in blah is locked. This is desirable behavior; I would like to catch this error and use it to inform my application logic. But I want to re-throw any other SQL errors, because they're different than the case I'm programming for, and catching them in the same way would be wrong.
The error object returned has a string error message, and a numeric code (50463045). It seems like comparing on the numeric code would be great, but I don't want to embed the constant 50463045 in my code without some modicum of understanding of how the heck it was determined. Notably, the Postgres manual suggests that the error code for this state is 55P03, and that doesn't seem to be the same thing. I don't have any idea how much I can trust this magic number, and how to determine it except for experimentally, so I'm not really comfortable with using it.
How is the error code determined?
The Internet was distressingly unhelpful, since searching for stuff about DataObjects SQL errors seems to mostly return problems with other software raising the errors, not information on the errors themselves... but after locating the right source code and browsing around through the source code I finally located do_postgres.c:
void do_postgres_raise_error(VALUE self, PGresult *result, VALUE query) {
const char *message = PQresultErrorMessage(result);
char *sql_state = PQresultErrorField(result, PG_DIAG_SQLSTATE);
int postgres_errno = MAKE_SQLSTATE(sql_state[0], sql_state[1], sql_state[2], sql_state[3], sql_state[4]);
PQclear(result);
data_objects_raise_error(self, do_postgres_errors, postgres_errno, message, query, rb_str_new2(sql_state));
}
Notice how a 5-character state is passed to MAKE_SQLSTATE... and then also passed to data_objects_raise_error itself. I couldn't track down where MAKE_SQLSTATE is defined to figure out what crazy manipulations are going on to make this integer, but it appears I can just use the error object's .sqlstate property directly, and make my condition e.sqlstate == '55P03'.