Introduction
In the High-Level Overview for this series I mentioned that I'll need a way to measure the success of this project as it progresses.
As this project's aim is to create a one for one replica of the Ruby implementation of Liquid's behaviour, I will be porting Liquid's integration tests to C# and following a test driven approach.
What's in a Name?
Though they have been called integration tests in Liquid's code, the majority of these tests are in fact functional acceptance tests, which is what makes them useful for confirming that the behaviour of the system is correct.
Unit Test
Tests the behaviour of a single system component in a controlled environment.
Integration Test
Tests the behaviour of major components of a system working together.
Functional Acceptance Test
Tests that the system, per the technical specification, produces the expected output for each given input.
Unit and integration tests verify that the code you've written is doing what it was written to do, while functional acceptance tests verify that the system as a whole, without consideration for the structure of its internal components, does what it is designed to do.
Any Port in a Storm
There are hundreds of tests to port to C# and, as it turns out, not all of the tests in the Ruby implementation's integration namespace are integration or functional acceptance tests... some are unit tests!
The porting process is therefore a matter of replicating the original tests as faithfully as possible, translating them into functional acceptance tests where needed.
A test that ported smoothly
# Ruby
def test_for_with_range
assert_template_result(
' 1 2 3 ',
'{%for item in (1..3) %} {{item}} {%endfor%}')
end
// C#
public void TestForWithRange()
{
AssertTemplateResult(
" 1 2 3 ",
"{%for item in (1..3) %} {{item}} {%endfor%}");
}
A test that needed translation
# Ruby - The below are unit tests
# for methods escape and h
def test_escape
assert_equal '<strong>', @filters.escape('<strong>')
assert_equal '<strong>', @filters.h('<strong>')
end
// C# - Rewritten as a test of the
// output expected from a template
public void TestEscape()
{
AssertTemplateResult(
"<strong>",
"{{ '<strong>' | escape }}");
}
When translating from a unit or integration test to a functional acceptance test, I'm using the documentation and wiki as the design specification. This ensures that the tested behaviour is the templating language's expected behaviour, not just the behaviour I expect!
What's Next?
Once all of the tests are ported, the next step will be to start writing the code to pass those tests. Remember, in Test Driven Development we start with failing tests and then write the code to make those tests pass.
The AssertTemplateResult method mentioned earlier currently looks like this:
protected void AssertTemplateResult(
string expected,
string source)
{
// TODO: implement me!
throw new NotImplementedException();
}
There's still a few hundred more tests to port yet, though, so wish me luck!
