HackerNews UWP - The Whole Item (almost)
In the last post we got the Title of the UWP app passing up the app. But it's not part of the app. There's no trigger for the app to LOAD the data. We have the mechanism; but where from?
Today we'll get the data load triggered from the screen loading. This will involve actual network activity... so we'll see how we can bring in UI tests.
Ui Test Project
I've added in a UI test project and poked at it a bit. I'll be doing a quick simple example checking that some data is put into the Title box; but not any in depth verification. The title box is gonna go away soon.
...
I played with the UI tests a bit. They seem pretty useful once they're in place. I had one running. I then realized I'd forgotten to pull... so I nuked it.
No More Ui Test Project
But I'll add it back in later. I could use it to drive implementation of some... haven't quite gotten there yet. Once I get to a better pivot point I'll switch to heavy investment into the UI project.
I'm looking at getting the list view in place before I move to UI tests.
In the effort I'm starting to create the Item XAML object to display. This will be done as a single control on the main page before later being moved into a ListView. Should be interesting to see how that gets refactored about.
I had a ItemDisplay control I was gonna plug everything into... but then I realized it's it's own "Hotel". Now it's called ItemView and it's gonna be built as it's own Hotel Pattern. I wonder if that's what I'm missing from Android to make the UI sing. I got a bit of clumsy stuff going on in Android for the display. Haven't liked it; didn't have better... even though I've designed the better solution. :\
Working on UWP right now; I see a better way; gonna work it in.
...
Still working through a bit of refactoring. I've got the Item Hotel pattern in place. I had to refactor some test support classes. I wasn't doing OOD on those... Realized it and refactored it into correctness. It feels much better.
...
I spent about 2 hours working on getting a test running; finally thought it should be passing - confused as all hell.
I just got home from work; looked at it and thought, "Where's it setting the fakeResponseHandler?" ... it wasn't... It is now. It passes.
This puts me very close to have an end to end for the Title of a story.
time passes
I started adding some new functionality to the code and failed to remember what I was actually trying to do. It was a good thought experiment and some code exists (yes, all TDD'd... but no pair crys) that I'll be keeping. I just have to refocus on getting a Title to display. That's all I need. Everything else; DO IT LATER!
Like building an ItemsList to be the hotel pattern for the List of items.
I checked some stuff in so I could work not at home. It might be broken... It was doing a bad thing... I need to make it do a not bad thing.
The issue is that I'm using my blog url for the root domain to hit. This'll need to be fixed for going forward. Makes me glad I switched it to a public variable recently and don't need to go change it in every test... I just hope I changed it in every test already.
"YES! IT FAILED!"... I say that a lot on this blog projects.
OK, I've updated the URL and re-run the code (not the tests) and YAY! It showed a title!
OK; now that I've gotten the start of an item; I need to expand out the item control and get the full display going on.
time passes
Checking out what we've got going on; looks like I need to expand the Item control to fully display the item data.
I'm going to start with the ItemElevator and TDD the Author into existence! There's probably not going to be a lot of excitement here. I have the title test; I expect the author test to follow pretty closely.
I'm not seeing the null items coming into existence yet... which is mildly interesting. I'm not sure when they started in the Android App; maybe I won't need them? I strongly suspect I will since some of the data doesn't exist for all items.
This is more of an Integration test than a Unit test. I'm torn on these. While I think that the more granular the better for driving implementation; the more of the system you can test the better. Going to unit for systems that are being driven by other components is going to create a lot of churn on the tests and classes. You can't know what it will need until it's being called from somewhere else.
But we should have test coverage of the class to have confidence in changes.
Which makes me torn. I bet if I had someone to pair with; there'd be better answers and better results.
Figured out where my distinction between unit test and integration test on my ItemElevatorTests were. I didn't actually have the method doing the work under test. It was checked via the integration; but ... I am feeling much better seeing the absence of tests on the ItemElevator#Update method; which is from the ItemConcierge.IItemElevator interface.
This needs to be remedied. It'll have a catch up test for the Title; but that should be the only one.
Oh... now I need to implement the Null Objects for lazy objection creation in tests!
Working on adding the Author class I've noticed a similarity between the TitleInto and AuthorInto methods; and that they're duplicating information. I'm changing these to just Into methods. I'm inclined to create an interface; to enforce this method... But haven't seen the driving need for it.
I really want it... Just... no NEED yet... grrr...
I apparently missed a few HostUrl changes. Clearly I do not run all the tests often enough.
One of the failing tests at this point is
[TestMethod, TestCategory("unit'")]
public void ShouldLoadCountInViewLoaded()
{
// Arrange
FakeMainPageView fakeMainPageView = new FakeMainPageView();
MainPageElevator mainPageElevator = new MainPageElevator(fakeMainPageView);
// Act
mainPageElevator.ViewLoaded();
// Assert
fakeMainPageView.TxtStoryCount.AssertAgainstText(text => text.Should().Be("3"));
}
But it's not really a valid test. It was useful originally to get some pieces in place, now... not so much. It dies.
After a lot of dancing around and mashing classes into other things... Author is ... passing. I almost said 'displayed', but I haven't tried that yet. I think I'll do that now.
... And... Nope. It still just displays into the original title box. Probably 'cause I'm not pulling the ItemControl from the view in the Elevator. I'll be back after checking that.
(but Noooo, you don't have to wait...)
Oh... kinda helps if I implement some functionality. New pain point; The Code Behind is still not TDD'd... So... Gonna have to refresh my mind on what I did for android; and if I can apply something similar here. More than /A/ UWP UI might help... maybe.
... it's all broken. I broke it all. I'm getting food. Eat. It's important for good code production.
*time passes
Wow... I really was hungry stupid. I had to update the HostUrl from hard coded values in the test to use the actual code URL (which should be changed to a test thing). There's still some failures; but that was the first issue. Now I'm faced with getting the correct data into the JSON so that the responses can be parsed.
Down to just one failing test. ShouldLoadCountInViewLoaded which should go away. We're no longer concerned about displaying the count value. It was a temporary thing to get the pipeline working without worrying about the contents of the Json.
After changing the ShouldLoadCountInViewLoaded to be ShouldLoadTitleFromViewLoaded I kinda had a better idea of what I was going for with the test.
I had to hook up a JSON response; and then was able to get the data parsed and returned and my test passing.
MainPageElevatorTests#ShouldLoadTitleFromViewLoaded now looks like
[TestMethod, TestCategory("unit'")]
public void ShouldLoadTitleFromViewLoaded()
{
// Arrange
FakeMainPageView fakeMainPageView = new FakeMainPageView();
MainPageElevator mainPageElevator = new MainPageElevator(fakeMainPageView);
FakeResponseHandler fakeResponseHandler = new FakeResponseHandler();
fakeResponseHandler.AddFakeResponse(new Uri($"{HackerNewsAccess.HostUrl}/item/14448404.json"),
new HttpResponseMessage(HttpStatusCode.OK)
{
Content = new StringContent(@"{""id"":14448404, ""title"":""My First TitleInto""}")
});
new HackerNewsAccess(fakeResponseHandler);
// Act
mainPageElevator.ViewLoaded();
// Assert
fakeMainPageView.AssertAgainstTitleText(txt => txt.Should().Be("My First TitleInto"));
}
I refactored the FakeMainPageView.TxtTitle to be encapsulated. As can be seen in the line fakeMainPageView.AssertAgainstTitleText(txt => txt.Should().Be("My First TitleInto")); it cleans up the test a bit. It doesn't matter what I store the text in; it can test against it's value. Before it was expected to be AT LEAST an ISetText if not explicitly a FakeTextView. This is what even encapsulating our test "helpers" can gain us - Less fragile tests. It's a beautiful thing.
time passes
All my tests pass. I've done a bunch of refactoring and some tests got taken out without replacements. This was during some base laying, so they should be covered by other things.
I'm suspicious, so I ran coverage. Total... only 20%. What the hell..
Program - OK, start up
App - Also start up
XamlTypeInfo ... Yea; you can stay.
ItemElevator - WTF... I have tests for that... OH... It's the naming shit... My refactor put the elevator into a partial class; and it didn't correctly move the file into the Project; so the test version was still getting invoked.
My HackerNewsAccess ApiException handling wasn't TDD'd... Oops.
I think the ReSharper code coverage has issues with UWP async/await. It's marking a class at 0/0 and when I debug a test; it's hitting a line.
Figured it out. The method was an async Task and it needs async void. This makes many things happy.
Going through and transitioning all of async Task to async void and then will need to correct the callers. Which may be to make them non-async.
The only eyesores right now are the Hotel Views. I don't have enough examples to know how to effectively abstract away from the base code behind.
This will come with some experience, and I'll be able to improve it. Right now it'll sit as a book end with NO LOGIC; which will allow the 0% test coverage.
Getting the whole object
I've been struggling to get the whole object in place and I've finally realized why. I'm trying to operate on a collection as if it's a single thing. I haven't built in any of the "collection" aspects yet. I need to step back and reconfigure the flow to just get a hard coded story. I have that a little; and it works into a bare Text control for the title. This needs to be taken a step back; get the flow working for the "Item View" and then layer the collection on top of it.
I'm going to end this post. The next one will be a bit of a re-configure/Whole Item post