Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TDD Core Skill issues #22

Open
craigjbass opened this issue Jun 28, 2018 · 5 comments
Open

TDD Core Skill issues #22

craigjbass opened this issue Jun 28, 2018 · 5 comments
Assignees

Comments

@craigjbass
Copy link
Member

craigjbass commented Jun 28, 2018

Please create / link to sub-issues if wanting to discuss a specific topic.

Notes 1

  • Is the test fair if you're not familiar with ruby?
    • Could we test in people's preferred language?
    • Should people be expected to be able to perform tdd in ruby?
    • ...or to apply tdd to the unfamiliar?

Notes from running assessment with X

  • Rails really made this hard for X, and probably introduced a lot of stress, so I provided some assistance around Rails.

  • Feel like recognising fast feedback cycles should be giraffe or wolf.

  • I showed X how to skip the other tests because watching him wait was too painful.

  • Saw some good spiking around Rails to get their head around it (although no marks, sorry)

  • We hit the twitter rate limit and couldn’t run make serve for a period of time

  • Also provided some assistance around rspec

  • Writes only the simplest test

    • Initially was attempting to checking for 1 list item in the markup, which can be tricky. I asked some questions around this and they used string.includes? Instead of something more heavyweight
@craigjbass
Copy link
Member Author

Notes from running assessment with Y

  • Slow to setup and install application locally.
  • Is not saving username to begin with an oversight? Is it usefully annoying?
  • Guard probably a no IMO. Pro - speedier tests. Con - less reason to identify slowdown? Can’t see when candidate is choosing to run tests themselves?
  • Does implementing production code well matter? Do reasonable views matter?
  • Are there no marks for readability in tests and production code?
  • Suggested opportunity to use Webmock to refactor existing test suite.
  • Suggested removing database usage in new and existing tests to refactor.

@craigjbass
Copy link
Member Author

Under well-written tests: something about Hierarchical tests.

@craigjbass
Copy link
Member Author

Under well designed tests: Something about conciseness.

@danielburnley
Copy link
Contributor

We hit the twitter rate limit and couldn’t run make serve for a period of time

Potentially worth faking the actual twitter API with a simulator from another docker container? Maybe simulate latency there to keep web request time realistic (see: slow)

@naliwajek
Copy link

naliwajek commented Jun 28, 2018

I'm wondering how fair the current assessment guide is against people with most of their background in statically-typed languages.

Could you simply not think about some of the things from the marking guide because you’ve spent your whole life watching how the compiler does that for you? Should we then have some statically-typed languages in a mix as well? With a marking guide different a bit?

I don't have any specific examples in mind yet, I put that comment here just to be wary of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants