Refactoring Bootstrapper to introduce better coverage and testing #1603
Conversation
…Error # Conflicts: # paket.lock
…y implemented in StartPaketBootstrapping
…pUpdateError # Conflicts: # paket.dependencies # paket.lock
…so control silent mode via that
|
|
| var url = String.Format(Constants.PaketExeDownloadUrlTemplate, latestVersion); | ||
| ConsoleImpl.WriteDebug("Starting download from {0}", url); | ||
|
|
||
| //using (var httpResponseStream = WebRequestProxy.GetResponseStream(url)) |
There was a problem hiding this comment.
could you please remove commented code. Hurts my OCD ;-)
|
Yeah. Sorry for that. Didn't want to hurt you. |
|
@Stift great huge job! I wish we could write it in F#, in FP style, but we cannot. |
|
@vasily-kirichenko Thx. |
|
I think it's fine for now, but it would make a cool case study to refactor this further to get rid of mocks and interfaces in C#. |
|
You can get rid of interfaces and mocks, but then you use delegates all over the place and pass them around. At least, the code is still readable. As said before, I just wanted to have tests for now and increase the coverage on that tool. |
|
yes primary goal is to make that thingy useable and get everything under test. well done! |
I have completely refactored the bootstrapper. The initial problem why I started this is just that this simple tool got rather complex during the last year. In the beginning it was just ~80 lines, but more and more features were integrated which introduce also bigger complexity. Therefore, I refactored it to have some test in place and also removed some bugs which I discovered btw. I think this gives some benefit to all users of paket, as everyone checks in the bootstrapper and rely on its correct functionality.
The following items are tested from now on:
I also improved the CachedDownload strategy which before behaved like a bootstrapper on its own and now is only a strategy, and rely that the bootstrapper will do his job.
After refactoring we should have a test coverage of ~90%, before there was nearly none. The only downside is, that my refactoring increased the size of the bootstrapper by ~5kB, which is excusable if I look on the plus side.
Besides that the following bugs were removed
paket.bootstrapper.exe prereleaseand after thatpaket.bootstrapper.exe, the second call does not use the latest versionThe following features were also added.
I'm sorry for the bigger PR, but for me it seemed like the best way to succeed.