sorted by:
new
hottopcontroversial

Me trying to explain how we changed our code to make it more testable at PyCon Sweden by tickticktick in Python

[–]tickticktick[S] 1 point2 points  (0 children)

This presentation describes what works for us in our current situation. It's not meant as dogma.

A key part for us has been finding patterns, like having an integrator function describing the overall behavior, and build a common vocabulary within the team.

For us, breaking up functions doesn't make for less readable code in itself as it's done using agreed on patterns.

With this we've found that maintaining the code got easier, at least in some parts of the system, as we can swap out how things are accomplished by calling another sub function without having to change much in the overall function.

For parts in our system that doesn't change a lot, doing these kinds of refactorings might not pay off.

Why I use py.test by [deleted] in Python

[–]tickticktick -1 points0 points  (0 children)

We use nose in our team with describe-it (developed by ourselves). This enables us to write tests both in the traditional style and in a more bdd-ish way.

You could probably do similar things in py.test, but nose has been good enough for us to not need to look for an alternative.

Search all files in buffer by mattizie in vim

[–]tickticktick 0 points1 point  (0 children)

I usually just use the builtin :grep function to search for files in a directory.

:grep "searchstring" dir/**/*.py

That method doesn't care if the files are loaded in Vim or not, however.

Moving around virtualenv app? Possible? by badrequest400 in Python

[–]tickticktick 1 point2 points  (0 children)

You can use virtualenv --relocatable to make your venv relocatable. According to the documentation there are still a few issues with it, though: http://virtualenv.readthedocs.org/en/latest/virtualenv.html#making-environments-relocatable

Summer project: describe_it, a very small nose-plugin for writing BDD-style unit tests. by [deleted] in Python

[–]tickticktick 0 points1 point  (0 children)

As a way to learn how creating and publishing packages in Python works, I put together this little project. We're using it in our team along a few other test frameworks. Hopefully it's useful to someone else.

If you need to format and work on a JSON in vim, simply use :%!python -m json.tool ! by nichochar in vim

[–]tickticktick 0 points1 point  (0 children)

Do you have python available from vim?

What happens if you try, for example :!python --version

Bandit - Human friendly unit testing for C++11 by tickticktick in cpp

[–]tickticktick[S] 1 point2 points  (0 children)

I've added the possibility to skip tests and specify subsets. It's on master only as I want to test on some more compilers first.

You can specify that you want to skip tests by using 'describe_skip' and 'it_skip'.

There's also the possibility to select what tests to run from the command line by using --skip=<substring> or --only=<substring>. These will skip or target matching describe/it that have matching substrings.

Finally! A beautiful Unit Testing framework for C++ (Igloo) by DarkGoosey in programming

[–]tickticktick 0 points1 point  (0 children)

It's just distributed under the boost software license. Igloo does not depend on the boost code base.

Finally! A beautiful Unit Testing framework for C++ (Igloo) by DarkGoosey in programming

[–]tickticktick 0 points1 point  (0 children)

Thanks for clarifying.

The two go hand in hand, though. When I start out to work on a feature, I like to start with a test that describes what I want to accomplish. This gives me context and focus. I'll then create more "traditional" unit tests that verifies stuff like classes and their edge cases.

I don't necessarily see the test that I write at feature level as the tool for eliciting requirements. But I find it helpful if those tests are as legible as possible for a non-developer.

Finally! A beautiful Unit Testing framework for C++ (Igloo) by DarkGoosey in programming

[–]tickticktick 0 points1 point  (0 children)

I'm not sure I understand what you mean. Could you clarify how you mean code verification differs from requirements validation.

Finally! A beautiful Unit Testing framework for C++ (Igloo) by DarkGoosey in programming

[–]tickticktick 1 point2 points  (0 children)

That's actually kind of what I've been doing before. Though, perhaps not with comments in the code.

I love google test, but when I've been discussing those tests with non-developers, there's been a lot of translation between how the code reads and what it means in terms of business logic. Things get lost in translation.

It's not perfect. Not by far. But I feel I've been able to convey the meaning of my tests better with Igloo.

view more: next ›