Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Mohammad Hamdy Ghanem
@VBAndCs
I downloaded the source on win 7 x64 bit, and its tests failed, because github normalized the line terminatorof a multiline string to vblf while the test expected vbcrlf.
I don't know if this happens with files uploaded to github, or because I modified the file manually by pasting code in the github online editor.
I was cautious to normalize strings coming CDATA sections in my code, but now I have to normalize all strings to avoid this github issue :)
The fix is just callingSourceStr.Recplace(vbCrLf, vbLf)
Stephen A. Imhoff
@Clockwork-Muse
@VBAndCs - That depends - if you're only doing that for your test file, that's the wrong fix (you should ensure that the file has the proper line endings when uploaded by git). If it's in the normal hashing method, that's something you have to be upfront about to your callers, because otherwise your MD5 isn't going to be the same as stuff they might get elsewhere.
Also, why MD5? It's been deprecated for everything but certain legacy applications.
Stephen A. Imhoff
@Clockwork-Muse
And see this answer for some other options for converting to the byte string.
Mohammad Hamdy Ghanem
@VBAndCs
As I read, MD5 is still valid as a checksum, bit not secure for passwords. I just use it for testing.
Mohammad Hamdy Ghanem
@VBAndCs
The issue is that string literal uses vbCrLf, but CDATA and github use vbLf. I jst ensue to normalize the output string b4 hashing, and seems to work fine. SyntaxTree seems not complaining about vbCrLf ot vbLf, so, the functionality isn't affected.
Stephen A. Imhoff
@Clockwork-Muse
Checksum? Only from non-malicious (ie, accidental, bit rot) modification. Otherwise you need something else. If, for example, this is getting posted for download verification from mirrors, MD5 is not sufficient (you need SHA2 or better, currently).
The implication is that you're hashing one of your code files. Why?
CyrusNajmabadi
@CyrusNajmabadi
GitHub didn't care. This relates to your git client settings.
Do this @VBAndCs
git config --global core.autocrlf false
Now your git client won't change line endings
Mohammad Hamdy Ghanem
@VBAndCs

Now your git client won't change line endings

Nice. Thanks.

The implication is that you're hashing one of your code files. Why?

I decided to use hashing in test methods that test the generated code. Input line terminator doesn't matter, but the output must have the same hash that the one I am comparing to.

I am using a vb-like code to generate a record class. I am using Roslyn to parse my syntax. So, the input is code, and the output is also code.
Mohammad Hamdy Ghanem
@VBAndCs
I felt tired of pasting the whole long class in each test method, so, tried the hashing.
Assert.AreEqual(GetHash(result.Output), "BC7C020F61E28086AD90B7E27DA8B21E") seems nice :)
Stephen A. Imhoff
@Clockwork-Muse
... as opposed to comparing file contents, or a syntax tree diff? Which could even be used to tell you where the difference in the file is. If the hash is different now you have a mystery.
Also, updating the hash becomes a self-fulfilling prophecy for these tests: "I changed the generation, so the hash changes, and the test outputs the new hash..."

GitHub didn't care. This relates to your git client settings.

For this sort of situation I wish you could explicitly set certain files to be a specific file ending. Especially since I think GitHub may have mucked with them on top of things, too.

CyrusNajmabadi
@CyrusNajmabadi
I decided to use hashing in test methods that test the generated code.
I guess the question is: why?
Why not actually just validate the contents?
Assert.AreEqual(GetHash(result.Output), "BC7C020F61E28086AD90B7E27DA8B21E")
This seems completely not understandable. I have no way to know what the actual expected outcome is. So if somethign breaks all i get is a message saying "XYZ" != "ABC". that doesn't tell me why things are broken or what i would need to do to get a correct hash again.
Mohammad Hamdy Ghanem
@VBAndCs
Think of this as an Integral Test, where I check that the whole generator is working without exception, and the the output has the expected fingerprint.
<TestMethod>
    Public Sub NameValue()
        Dim TestRecord = <![CDATA[Public Record NameValue(Name ="", Value = 0.0)]]>.Value
        Dim result = GetGeneratedOutput(TestSourceCode, TestRecord)
        For Each diag In result.Diagnostics
            Assert.AreNotEqual(diag.Id, "BC42502", diag.ToString())
        Next
        Assert.AreEqual(GetHash(result.Output), "BC7C020F61E28086AD90B7E27DA8B21E")
    End Sub

    <TestMethod>
CyrusNajmabadi
@CyrusNajmabadi
yes. i get that. i'm saying: the test isn't meaningful. because if i get a different hash i have no way to ascertain if that's a good change in behavior, or an unwanted one.
the 'previous' result means nothing to me. no one can look at BC7C020F61E28086AD90B7E27DA8B21E and understand waht it means.
and if the new hash was different, having hte unit test say "you expected BC7C020F61E28086AD90B7E27DA8B21E, but got <something else>" isn't actionable.
Mohammad Hamdy Ghanem
@VBAndCs
I have another unit tests to test critical parts:

    <TestMethod>
    Public Sub WriteNameValue()
        Dim code = <![CDATA[(Name ="", Value = 0.0)]]>.Value

        Dim expected = <![CDATA[   <Key>
   <DefaultValue("1= #1/1/0001#")>
   Public Shadows Property [Date] As Date

   <Key>
   <DefaultValue("1=__QUOTE____QUOTE__")>
   Public Property [Name] As String

   <Key>
   <DefaultValue("1= 0.0")>
   Public Property [Value] As Double


]]>.Value

        Dim properties As New List(Of PropertyInfo)
        Dim result = WriteProperties(code, properties, "Inherits Test").Replace(vbCrLf, vbLf)
        Assert.AreEqual(result, expected)


        expected = <![CDATA[    Public Sub New(
                Optional [date] As Date = #1/1/0001#,
                Optional [name] As String ="",
                Optional [value] As Double = 0.0
            )

        Me.Date = [date]
        Me.Name = [name]
        Me.Value = [value]
    End Sub

]]>.Value

        Dim sb As New StringBuilder
        RecordParser.WriteConstructor(properties, sb)
        result = sb.Replace(vbCrLf, vbLf).ToString()
        Assert.AreEqual(result, expected)


        expected = <![CDATA[    Public Function [With](
                Optional [date] As Date? = Nothing,
                Optional [name] As [Optional](Of String) = Nothing,
                Optional [value] As Double? = Nothing
            ) As NameValue

        Return  New NameValue(
            If ([date].HasValue, [date].Value, Me.Date),
            If ([name].HasValue, [name].Value, Me.Name),
            If ([value].HasValue, [value].Value, Me.Value)
        )
    End Function

]]>.Value
        sb.Clear()
        RecordParser.WriteWith("NameValue", "", properties, sb)
        result = sb.Replace(vbCrLf, vbLf).ToString()
        Assert.AreEqual(result, expected)

    End Sub
CyrusNajmabadi
@CyrusNajmabadi
none of that addresses teh point i made about your test :)
if it fails. it's not actionable.
Mohammad Hamdy Ghanem
@VBAndCs
@Clockwork-Muse Any change in the generator that changes the output, will need to change all the tests expected values, using hashing or plain strings.
CyrusNajmabadi
@CyrusNajmabadi
Any change in the generator that changes the output, will need to change all the tests expected values
taht's not necessarily true
it will be true if you're doing an exact check of contents (which is up to you)
you could, for example, do a whitespace-insensitive check, if you want your tests to effectively say: i don't care if whitespace changes
the hashing approach is somewhat the worst of all worlds
Stephen A. Imhoff
@Clockwork-Muse

you could, for example, do a whitespace-insensitive check, if you want your tests to effectively say: i don't care if whitespace changes

Right, this

CyrusNajmabadi
@CyrusNajmabadi
it always changes whenever the output cahnges (no matter how slight). but it gives the least amoutn of information about what changed.
it soundsl ike you want hte opposite. you want slight changes in your output to to not cause assertion failures.
Stephen A. Imhoff
@Clockwork-Muse
Which is why I brought up the point about syntax tree checking, because often for generators you don't care what it looks like.
Mohammad Hamdy Ghanem
@VBAndCs

if it fails. it's not actionable.

If NameValue integral test fails, I will run WriteNameValue and see what is going on.

CyrusNajmabadi
@CyrusNajmabadi
I will run WriteNameValue and see what is going on.
why don't you just always run this then :)
they're tests :)